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Until  recently,  much  of  the  budget  planning  for  software 
systems  has  been  primarily  targeted  at  costs  incurred  during 
the  development  phase.  However,  with  increasing  software 
system  life  span  and  complexity,  maintenance  costs  have 
become  a  mere  prevalent  concern.  As  a  result  of  necessary 
corrections  for  design  errors  and  evolutionary  maintenance, 
post-delivery  investment  in  software  systems  now  requires  a 
greater  proportional  share  of  the  life-cycle  costs.  In  this 
research,  various  methodologies  and  system  factors  relating 
to  software  cost  accounting  are  reviewed  with  the  intent  of 
developing  a  cost  ccntrcl  model  for  arriving  at  a 
well-structured  view  for  the  management  of  the  maintenance 
phase  of  the  software  life-cycle.  The  model  proposed 
embodies  a  planning  concept  for  establishing  a  maintenance 
strategy  and  a  control  concept  for  analyzing  manloading 
requirements  during  the  maintenance  phase. 
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I .   I NT RO DUCT ION 

k.       THE  PROBLEM 

Recent  literature  is  replete  with  dire  predictions  about 
the  ultimate  costs  of  software  maintenance.  In  1973,  costs 
of  software  in  the  United  States  were  $20  billion  [1]  and 
they  are  projected  to  be  $200  billion  in  1985  [2].  It  has 
been  hypothesized  that  anywhere  from  forty  to  ninety-five 
percent  of  the  manpower  effort  in  typical  industrial  appli- 
cations occurs  during  the  maintenance  phase  of  the  software 
life  cycle.   [3,  4,  5,  6,  7,  8,  9,  10,  11,  12,  13,  14] 

Although  there  are  numerous  models  in  existence  that 
deal  with  software  costs,  none  deal  specifically  with  the 
costs  of  •pure*  maintenance  during  the  latter  phase  of  the 
software  life-cycle.  It  appears  that  much  of  the  Federal 
Government  and  industry  tend  to  use  a  general  definition  of 
software  maintenance  and  treat  it  as  a  level  of  effort  on 
various  tasks  rather  than  that  effort  allocated  to  specific 
tasks.  Consequently,  these  organizations  do  not  really 
know   the  true  ccsts  cf   their  software  maintenance. 

The  goal  of  this  work   is  to  investigate  the  methodology 

of  software  cost  accounting,   and   to  evaluate  and  develop  a 

cost  model  for   the  prediction  of  pure   software  maintenance 

costs. 
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3.   3ACKGRCUNB 

The  term  'Software  Maintenance*  is  very  nebulous.  De- 
partment of  Defense  Directive  5000.29  alludes  to  software 
maintenance  by  stating: 

"Correctness  of  software,  reliability,  integrity,  main- 
tainability, ease  of  modification,  and  transferability 
will  be  major  considerations  in  the  initial  design." 
[15] 

Used  in   this  thesis  is   a  composite  definition   of  software 

maintenance  to   encompass  those   actions  taken   by  a   system 

user  to  retain  an  existing  system  in,   cr  restore  it  to,   an 

operable  condition.   This  includes: 

1)  corrections  to  counteract  detected  tugs; 

2)  enhancements  to  add  functions; 

3)  modifications  to  delete  or  change  existing  functions  in 
their  nature  or  scope; 

4)  implementation  strategy  to  match  changed  conditions  or 
requirements.   [16,  17,  18,  19,  20,  21,  22,  23,  24] 

•Pure'  Maintenance  on  the  other   hand  is   restricted  to 

that  work  accomplished  during  the  maintenance  phase   of  the 

software  life  cycle  in  the  pursuit  of  the  following  goals: 

1)  Relialibility  of  Software  -  the  ability  of  the  software 
to  produce  consistent  results  whenever  the  customer 
uses  the  product; 

2)  2rror  Correction  -  changes  made  to  counteract  errors. 
The  priority  of  correction  is  directly  related  to  the 
seriousness  of  the  error; 

3)  Software  Maintainability  -  extending  the  useful  life  of 
a  oroaram  by  untangling  a  messy  one,  generalizing  a 
specific  one,  cr  annotating  an  unreadable  one. 
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Robert  Glass  [25]  defines  the  best  software  maintenance 
as  no  maintenance  at  all.  That  is,  no  changes  are  needed  be- 
cause no  errors  were  committed  and  all  changes  were  antici- 
pated. He  then  goes  on  to  list  six  attributes  of  software 
maintenance: 

1)  Maintenance  is  intellectually  very  difficult.  Problems 
cannot  be  bounded.  The  cause  cculd  be  anywhere. 

2)  Maintenance  is  technically  very  difficult.  Problems 
cannot  be  specialized.  They  could  surface  because  of 
errors  in  the  coding,  design,  architecture,  cr  concept. 

3)  Maintenance  is  unfair.  Usually  the  person  who  is  main- 
taining a  product  did  not  write  it  and  must  interpret 
what  the  original  author  meant.  Documentation  is  in- 
adequate most  of  the  time. 

4)  Maintenance  is  nc-win.  People  only  come  to  maintenance 
with  problems. 

5)  Maintenance  is  infamous.  There  is  very  little  glory, 
noticeable  progress,  or  chance  for  'success'. 

6)  Maintenance  lives  in  the  past.  The  general  quality  of 
code  being  maintained  is  often  terrible.  This  is  part- 
ly because  it  was  created  when  everybody's  understand- 
ing of  software  was  mere  rudimentary,  and  partly  be- 
cause a  great  deal  of  code  is  produced  by  people  before 
they  become  really  good  at  programming. 

Researchers  dc  not  appear  to  be  using  the  same  defini- 
tion when  working  on  the  costs  of  maintenance.  Those  who  es- 
timate maintenance  costs  to  be  near  forty  percent  of  life- 
cycle  costs  seem  to  be  using  a  definition  closer  to  that  of 
•pure'  maintenance  while  those  who  estimate  maintenance  as 
high  as   ninety-five    percent  are  obviously  using   a  very 
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general  definition.  According  to  recent  surveys,  most 
(seventy  to  eighty-eight  percent)  maintenance  effort  is 
spent  modifying  software  to  accomodate  changes  and  to  im- 
prove software  performance  rather  than  to  correct  errors 
which  were  not  discovered  during  systems  development.  [26, 
27,  28]  These  surveys  have  been  substantiated  by  analyses 
done  on  three  large  scale  systems: 

1)  Pacific  Telephone  -  Service  Order  Retrieval  and  Distri- 
bution System; 

2)  Bell  Telephone  Laboratories  -  Automated  Repair  Service 
Bureau  System; 

3)  VISA,  Inc.  -  Base  II  World  Wide  Credit  Card  Transaction 
Interchange  System.   [29] 

Although  hardware  costs  have  decreased  by  over  two 
orders  of  magnitude  and  programmer  productivity  has  in- 
creased by  one  order  of  magnitude  in  the  last  ten  years,  the 
total  costs  of  systems  are  continuing  to  rise  with  the 
greatest  portion  of  effort  and  cost  spent  after  development 
completion  [30].  There  appear  to  be  four  primary  reasons 
for  this  phenomenon: 

1)  Maintenance  is  people  intensive; 

2)  The  number  of  systems  has  increased  substantially; 

3)  The  mission  of  the  software  seems  to  be  expanding; 

4)  Average  system  life  has  increased  from  three  years  in 
1960  to  five  years  in  1970  to  eight  years  in  1930. 
[31,  32] 
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A  recent  DOD  study  reports  that  development  costs  for 
Air  Force  avionics  software  averaged  575  per  instruction 
while  maintenance  costs  lie  in  the  range  of  $4,000  per  in- 
struction [33]  This  indicates  that  ninety-eight  percent  of 
the  life-cycle  costs  of  that  system  are  spent  en  software 
maintenance.  Another  study  concludes  that  fifty  percent  of 
the  costs  for  Navy  Airborne  Antisubmarine  Warfare  Tactical 
Software  is  spent  on  maintenance  software  [34].  As  one  can 
see,  there  are  many  different  meanings  of  the  term  'software 
maintenance1  and  as  many  different  assessments  of  its  cost. 

The  software  industry   does  not  appear  to   be  unified  in 

its  approach   to  decreasing  the  high   ccst  of   maintenance. 

McClure  states: 

"A  solution  that  focuses  upon  the  production  phases  of  the 
software  life  cycle  does  not  address  the  major  portion  of 
the  maintenance  effort...  We  must  directly  address 
maintenance  issues  rather  than  hope  that  they  will  disap- 
pear by  improving  the  development  process."  £-35] 

Most  of  the  literature  expounds  the  theory  that,  to  be  done 
properly,  software  maintenance  should  be  a  conscious  goal 
from  the  beginning  cf  the  software  development  process. 
Maintenance  is  ail  too  often  left  out  of  planning  considera- 
tions and  then  treated  as  a  helter-skelter,  uncoordinated 
activity  rather  than  a  planned,  methodical,  controlled  nec- 
essary business  function  [36].    Long  term  planning,  just  as 
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in  ether  disciplines,  includes  the  provision  of  appropriate 
tools.  There  are  two  major  categories  cf  tools  for  mainte- 
nance. Technical  tools  encompass  such  things  as  compilers, 
traps  ana  traces,  dumps,  comparators,  editors,  reformatters, 
and  preprocessors.  Administrative  tools  include  problem  re- 
porting vehicles,  status  reporting  vehicles,  and  documenta- 
tion systems.   [37,  38,  39] 

Even  with  the  knowledge  and  use  of  these  tools,  produc- 
tivity, which  is  typically  measured  in  software  lines  of 
code  (SLOC)  is  substantially  lower  for  maintenance  program- 
mers than  for  development  programmers.  According  to  Daly, 
maintenance  productivity  can  be  as  low  as  twenty  percent  of 
development  productivity  [40].  There  appear  to  be  three 
main  reasons  for  this  phenomenon: 

1}  There  is  a  stigma  attached  to  the  job  of  software 
maintenance.  Management  rarely  rewards  good  woric  in 
doing  maintenance  as  generously  as  good  work  in  doing 
development.  Both  coworkers  and  manaaement  personnel 
act  as  though  they  held  maintenance  worfc  in  low  esteem. 
To  survive,  every  person  must  have  self  respect.  If  a 
job  is  not  perceived  as  important,  a  person  probably 
will  not  perform  to  the  best  of  his  abilities. 

2)  Usually,  maintenance  personnel  are  not  intimately  fa- 
miliar with  the  cede  that  they  are  assigned  to  main- 
tain. Typically,  a  maintainer  is  assigned  responsibil- 
ity for  30,000  SLOC  [41].  Eecause  documentation  is 
guite  often  poor,  the  maintainer  must  study  the  code 
itself  and  try  to  understand  what  the  original  develop- 
er created  and  why  he  implemented  it  in  that  manner. 
Usually  ha  must  study  a  great  deal  more  code  than  the 
affected  area  to  avoid  inducing  bugs  in  a  seemingly  un- 
related area  by  the  fix  that  is  implemented. 


3)  The  wrong  grade  of  people  are  typically   used  to  staff 
maintenance  efforts  [42,  43,  44,  45,  46,   47,   48t   49] 

Traditionally,  maintenance  efforts  are  oemg  starred  by 
less  experienced   personnel  than   development  projects. 
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However,  maintenance  personel  should  be  senior  people 
because  software  maintenance  is  a  microcosm  of  the  en- 
tire software  development  process.  The  maintainer  does 
a  systems  analysis  of  a  problem  area  leading  to  a  re- 
quirements definition.  Donning  a  designer's  hat,  tne 
maintenance  person  then  outlines  the  impact  of  the 
change  on  the  product.  Being  a  flexible  individual, 
the  maintainer  now  codes  the  design  solution.  After 
the  results  of  these  efforts  have  been  tested  and  veri- 
fied, the  revised  product  is  finally  released  to  the 
world.  The  maintenance  person  also  plays  a  liaison 
role  with  the  customer  by  explaining  anomalous  outputs, 
negotiating  changes  that  are  needed  as  opposed  to  those 
that  are  desired,  and  interpreting  the  computers 
unique  constraints.  As  you  can  see,  the  person  «ho 
maintains  a  complex  system  should  be  a  highly  talented 
and  motivated  individual.   [50,  51,  52] 


C.   RESEARCH  METHCDOLCGY 
1 •   Literature  Search 

Manual  searches  and  automated  system  searches  of  the 
literature  showed  little  had  been  published  in  this  field. 
Although  there  is  a  lack  of  published  material  that  deals 
directly  with  a  fiscal  approach  to  planning  and  control  of 
software  maintenance,  the  researchers  found  a  great  deal 
that  was  very  useful  as  background  information  and  which 
helped  to  develop  the  theory  for  the  planning  and  control 
model . 

2.   Telephone  Conversations 

Efforts  to  uncover  informal  sources  that  deal  spe- 
cifically with  the  costs  of  'pure  maintenance1  failed.  The 
following  organizations  were  contacted  in  the  course  of  the 
research,  with  no  significant  results: 

Army  Computer  Systems  Command,  Ft.  Belvoir,  Va.  ; 

DOD  Computer  Institute,  Washington,  D.C.; 
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FEDSIM,  Washington,  D.C.; 

Homestead  Software  Support  Facility,  Homestead,  PI. ; 

IBM  Federal  systems  Division,  Gathersburg,  Md.; 

Kapur  Associates,  Danville,  Ca. ; 

National  Security  Agency,  T303,  Ft.  Meade,  Md. ; 

Naval  Security  Group  Activity,  Sfcaggs  Island,  Ca. ;  and 

NARDAC  San  Francisco,  Alameda,  Ca. 

Maintenance  tracking  data,  dealing  with  Goddard 
Space  Flight  Center  projects,  was  obtained  from  the  Data  and 
Analysis  Center  for  Software,  Griffis  AFB,  NY.  Unfortunate- 
ly,  the  late  arrival  of  the  data  and  format  incompatibility 
precluded  inclusion  of  this  data. 

Unpublished  documents  describing  a  matrix  management 
method  of  functional  area  analysis  developed  by  Mr.  Kyle 
Rone,  IBM  Federal  Systems  Division,  Houston,  Tx.  were 
obtained  and  significantly  contributed  to  the  formulation  of 
the  final  model. 

D.   ORGANIZATION  OF  THE  THESIS 

In  this  introduction  the  problem  has  been  stated,  its 
importance  discussed,  and  it  has  been  placed  in  the  context 
of  the  overall  computer  system  development  process.  Chapter 
two  covers  various  aspects  of   the  problems  encountered  when 
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estimating/determining  the  cost  of  software  maintenance. 
This  specific  background  material  is  needed  to  understand 
the  models  that  will  be  presented  in  chapters  three  and 
four.  Chapter  three  thoroughly  discusses  existing  models  in 
two  areas:  those  that  work  with  Norden-Rayleigh  curves,  and 
those  that  encompass  complexity  metrics.  Chapter  four  gives 
the  authors'  model  which  is  based  on  both  macro-estimating 
(total  system)  and  micro-estimating  (unit  composition)  tech- 
niques. Finally,  chapter  five  summarizes  the  thesis  and 
puts  forth,  conclusions  and  recommendations. 


20 


II.   QUANTIFYING  SOFTWARE  MAINTENANCE 

A.   THE  SOFTWARE  EROBLEM 

There  are  two  main  reasons  that  maintenance  has  become  a 
predominant  cost  in  software  systems.  First,  the  volume  of 
completed  systems  which  require  maintenance  dominates  the 
systems  under  development  as  more  and  more  long-lived  large 
systems  are  completed  and  delivered.  Second,  software  sys- 
tems require  a  considerably  greater  proportional  investment 
in  error  correction  and  evolutionary  maintenance  after  de- 
livery than  other  engineering  products. 

Numerous  technological  advances  have  not  solved  software 
problems.  They  have  increased  the  demand  for  software,  and 
opened  up  opportunities  to  use  computers  in  new  applications 
which  place  increasingly  severe  demands  on  software  tech- 
nology. Often  the  tendency  is  simply  to  ignore  these  prob- 
lems. Because  these  problems  are  both  technical  and  mana- 
gerial in  their  scope,  a  "systems  engineering"  solution  is 
needed. 

Unlike  hardware  operation  and  support  models,  where  the 
cost  of  spares,  maintenance  manhours,  material,  training, 
etc.,  can  be  estimated  based  on  some  physical  characteris- 
tics of  the  system,   software  maintenance  effort  is  strictly 
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a  function  of  manhours  to  perform  the  necessary  action. 
Thus  far,  maintenance  cos-s  for  software  seem  to  be  primari- 
ly an  estimate  by  an  expert,  someone  familiar  with  the 
changes  to  be  made  to  a  program,  rather  than  putting  certain 
parameters  into  a  cost  estimating  relation  and  calculating 
annual  maintenance  costs. 

Software  maintenance  costs  cannot  be  ascribed  to  one 
specific  agent  or  event  but  instead  to  the  combined  action 
of  many  factors.  By  reviewing  some  of  these,  the  complexity 
of  the  problem  can  be  better  understood.  In  this  research, 
an  attempt  is  made  tc  isolate  areas  that  can  be  estimated  by 
formulas  and  then  to  establish  the  mathematical  relation- 
ships. As  such,  the  following  topics  will  be  discussed  as 
they  relate  to  the  maintenance  function: 

1)  Software   Life-cycle; 

2)  Life-cycle   Interrelationships; 

3)  Software  Evolution; 

4)  Productivity; 

5)  Complexity  Metrics;  and 

6)  Error  Prediction. 
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B.   THE  SOFTWARE  LIFE-CYCLE 

In  the  mid  1970* s,  the  phrase  "software  life-cycie"  was 
coined  and  became  a  popular  means  for  conveying  the  basic 
concepts  of  a  software  system:  multiple  phases  and  extended 
life.  Many  representations  of  the  life-cycle  exist;  by  com- 
monly accepted  practice,  the  software  life-cycle  consists  of 
the  development  phase  and  the  maintenance  phase  taken  col- 
lectively. Depicted  in  Figure  2,1  is  a  composite  schematic 
showing  this  relationship. 

This  diagram  oversimplifies  the  importance  of  the 
maintenance  phass.  A  more  accurate  role  of  the  maintenance 
function  is  detailed  in  the  life  cycle  model  (figure  2.2) 
developed  by  Some  Air  Development  Center  [53].  From  this 
view,  maintenance  performed  during  the  operation  and  support 
phase  is  seen  to  be  a  highly  interactive  process.  The  con- 
jecture apparent  from  the  diagram  is  that  the  same  procedur- 
al requirements  fcr  software  development  must  be  duplicated 
during  the  maintenance  phase. 

The  basis  of  applying  a  life-cycle  management  scheme  to 
software  is  to  direct  attention  to  all  phases  encompassed  by 
the  system  life-cycle  and  the  contribution  of  each  phase  to 
the  total   life-cycle   expenditures.    Familiarity   with  and 
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Figure  2.1.   Software  Life-cycle  -  Composite  Schematic 
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Pigure   2.2.      Software   Life-cycle 
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understanding  of  the  life-cycle  can  help  managers  make  ef- 
fective distribution  of  the  resources  for  a  software  system 
which  will  ultimately  affect  the  maintainability  of  the 
software. 

The  life-cycle  curves,  more  recently  called  "Rayleigh" 
curves,  were  orginally  formulated  by  Lord  Rayleigh,  the 
3ritish  Nobel  Laureate.  Presently,  these  curves  are  used  to 
represent  resource  allocation  (manpower)  of  a  software  pro- 
ject. Preliminary  research  in  this  area  was  directed  at  re- 
source consumption  in  research  and  development  (R&D)  pro- 
jects. In  a  series  of  studies  conducted  by  Peter  Norden 
[54]  of  IBM,  it  was  established  from  a  large  body  of  empiri- 
cal evidence  that  large  RSD  projects  follow  a  life-cycle 
pattern  as  described  by  the  Rayleigh  (manpower)  equation: 

2 
-at 
y'  =  2Kate  (2.1) 

where 

y1    =   the   number   of   person-years     of   effort    expended 

per   year, 
K      =    the   total   number   of    person-years    required   over 

the   life-cycle, 
a      =    the   curve   shape    parameter, 
t      =   elapsed  time    in   years,    and 
e      =   exponential   function. 
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The  principle  of  the  curve  is  as  follows:  Research  has 
indicated  that  there  are  regular  patterns  of  manpower  build- 
up and  phase-out  in  complex  projects.  These  patterns  are 
made  up  of  a  small  number  of  successive  phases  or  cycles  of 
work  thoroughout  the  life  of  the  project.  Norden  linked  the 
cycles  to  obtain  a  project  profile.  When  the  individual 
cycles  are  added  together,  they  produce  the  profile  of  the 
entire  project  (figure  2.3). 
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Figure  2.3.   Project  Profile 


Peak  manloading  time  (t  )  culminates  during  final  stages 

d 

of  development   and  impie mentation  (figure  2.4)  .   Based  upon 
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Norden's  studies  [55],  cumulative  resource  allocation  up  to 
this  time  accounts  for  approximately  forty  percent  of  the 
life-cycle.  Occuring  at  the  low  end  of  the  curve  is  the  op- 
eration and  maintenance  phase  which  absorbs  the  remaining 
sixty  percent  of  life-cycle  expenditures.  The  greater  por- 
rion  of  costs  associated  with  this  phase  are  attributed  to 
the  "maintenance  tail"  or  expected  life  of  the  software  pro- 
duct. Failure  repair,  however,  is  just  a  small  part  of 
post-delivery      maintenance   activities.  studies  [56]      show 

that  coding  errors  account  for  only  thirty  percent  of  the 
post-delivery  errors.  The  greater  share  (seventy  percent)  is 
occasioned  because  there  is  a  mistake  in  design  or  specifi- 
cation. Although  the  code  performs  exactly  as  designed,  this 
dees   not   reflect    the   original   operational  desires. 
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Logically,  it  would  seem  that  maintenance  manpower 
requirements  would  decrease  over  time  due  to  growth  in  reli- 
ability. In  other  words,  as  programming  and  design  errors, 
which  are  commonly  called  "bugs",  are  found  and  corrected, 
the  time  to  the  next  system  failure  should  increase  through- 
out the  maintenance  phase  of  the  life-cycle.  This  reliabil- 
ity assumption,  however,  is  disputable.  Maintenance  action 
taken  in  response  to  error  cccurance  can  have  three  possible 
outcomes: 

1)  the  actual  error  is  corrected; 

2)  the  error   is  corrected,    but  the  fix   induces  a  new 

error ; 

3)  the  error   is  not  corrected,    and  the   program  remains 
non -operational. 

Reliability  growth,  then,  is  a  probabilistic  event  which  de- 
pends heavily  on  the  skills  of  the  maintenance  programmers. 
If  the  maintainers  are  competent,  reliability  should  grow. 

Another  controversial  assumption  is  growth  in  maintain- 
ability. When  maintainability  is  viewed  as  the  time  re- 
quired to  return  a  software  system  to  an  operating  status 
following  a  system  failure  and  maintainability  growth  is 
viewed  as  the  decrease  in  time  required  to  correct  an  error, 
then  an  obvious  conclusion  would  be  growth  in  maintainabil- 
ity.   Several  factors,   however,    may  produce  an  opposing 
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conclusion,  i.e.  decaying  maintainability.  Patchwork  fixes, 
in  addition  to  introducing  new  errors,  may  produce  module 
interface  problems  and  documentation  inefficiencies  will 
complicate  the  finding  of  other  errors.  Reduced  familiarity 
with  a  software  system,  stemming  from  frequent  personnel 
turnover,  can  be  an  inhibitor.  Documentation  and  software 
(programming)  standards  and  controls  may  not  be  enforced  on 
new  releases.  Error  identification  and  correction  may  be- 
come further  entangled  when  configuration  control  is  lax. 
Again,  the  competence  of  the  maintainers  will  influence  rhe 
results. 

C.   LIFE-CYCLE  INTERRELATIONSHIPS 

The  management  process  for  the  maintenance  of  software 
involves  decisions  in  establishing  control  of  changes  to  the 
software  and  in  providing  for  the  implementation  of  improved 
functional  capability  throughout  the  life-cycle  of  the  soft- 
ware. The  planning  to  acquire  and  implement  resources  for 
software  maintenance  must: 

1)  consider  the  entire  life  of  the  software,  and 

2)  begin  early  in  the  life  of  the  software  in  order  to 
reserve  funding  and  identify  sufficient  resources  for 
the  future. 
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Different  time  spans  and  levels  of  effort  exist  for  the 
different  phases  of  a  software  project.  The  failure  to  ob- 
tain quantitative  relationships  of  a  precision  comparable 
to  those  available  for  estimating  the  costs  of  hardware  sys- 
tems has  led  to  the  belief  that  interrelationships  exist 
among  life-cycle  phases.  That  is,  the  amount  of  resources 
used  in  early  phases  impacts  heavily  en  the  resource  re- 
quirements for  later  phases.  Using  an  approach  similiar  to 
basic  economic  production  theory,  Thibodeau  and  Dodson  [57] 
developed  a  mathematical  mcdel  to  describe  the  complexity  of 
the  phase  interrelations.  This  relationship  is  given  in  the 
form: 

a  b 
Q  =  AK  L  (2.2) 

where 

Q    =   the   level   of    output, 
K   =   the   amount   of    capital    input, 
L   =   the    amount   of   labor,    and 

A,    a,    and   b   are   empirically  derived   constants. 
Graphically,    this   is   shown   in   figure   2.5. 

To  add  a  tern  representing  technological  change  or  to 
account  for  different  classes  of  labor  or  capital,  the  num- 
ber  of   input    resources   can   be   expanded    to 

a1      a2      b 
Q    =    AK         K         L  (2.3) 

12 
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Figure   2.5.      Economic   Production    Curve 
In    order      to   indicate  trade-offs   between     life-cycle   phases, 


the   same    general    formulation   can   be   used   and  expressed   as 

(2.4) 


b     c      d     k 

P    =    aX      X      X      X 
d     c      t      n 


where 

P  =  software  production  resulting  from  the  applica- 
tion of  the  resources, 
X  =  person-months  of  inputs, 

a,   b,   c,   d,   and  k  are  empirically  derived  con- 
stants, and 

subscripts  d,  c,  t,  ra  represent  designing,   coding, 
testing,  and  maintenance  respectively. 

A  further  assertion   made  by  Thibodeau  and   Dodman  indi- 
cated that  limitations  in  design  resources  (e.g.  a  reduction 
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in  planned  resources)  may  be  passed  through  the  development 
phases  with  final  impact  in  the  maintenance  phase  (higher 
error  rates) .  Based  on  the  mathematical  postulate  previous- 
ly described,  this  type  of  relationship  can  be  shown  by  the 
graph  in  figure  2.6. 
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Figure  2.6.   Application  of  Production  Theory 

In  describing  the  infinite  set  of  relationships,  table  I 
illustrates  some  departures  from  the  ideal  which  may  occur, 
and  how  a  reduction  or  increase  of  resources  in  these  phases 
will  be  reflected  in  the  error  rate  of  the  delivered  soft- 
ware. While  it  can  be  argued  that  the  ideal  error  rare  may 
be  zero,  a  more  practical  solution  would  be  to  avoid  de- 
dicating an  enormous  amount  of  resources  to  achieve  zero 
errors.   As  a   result,   it  would  be   expected  -chat   for  mosi 
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information  systems,  planning  would  allow  for  some  marginal 
error  rate.  However,  this  tolerance  of  errors  does  not  nec- 
essarily apply  to  tactical  defense  systems. 

D.   SOFTWARE  EVOLUTION 

Operational  software  systems  undergo  a  continuing  pro- 
cess of  evolution,  the  phases  of  which  are  repair,  modifica- 
tion, enchancement,  and  adaptation.  Continuing  evolution  is 
the  visible  sign  of  continuing  interaction  between  the  sys- 
tem and  its  environment.  Even  if  — and  this  rarely,  if 
ever,  occurs —  its  first  implementation  was  perfectly  con- 
ceived, perfectly  designed,  and  perfectly  implemented,  a 
program  will  require  general  maintenance. 

Evolution  dynamics  is  a  theory  describing  the  change  of 
a  software  system  over  a  period  of  time.  The  theory  distin- 
guishes between  progressive  work  (to  introduce  new  features) 
and  antigressive  work  (fault  correction,  testing  activity, 
and  investment  in  methodology  to  combat  the  complexity  which 
grows  with  system  size)  [53].  The  basic  assumption  of  pro- 
gramming evolution  dynamics  is  that  it  is  legitimate  and 
necessary  to  view  a  large  program  and  its  maintenance  orga- 
nization as  interacting  systems.  Thus  one  must  search  "for 
lodels  that  represent  laws  that   govern  the  dynamic  behavior 
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TABLE  I 
Hypothetical  Phase  Interrelationship  Trade-offs 


Hypothetical  cases 

, 

112     3     4     5     6     7     8 

Analysis    and   design  >==<=>== 

Coding    and   checkout  =<<==><< 

Testing  =  =  >  =  =  ><  = 

Maintenance  ======>> 

Changes  No   No   No   No   Yes   Yes   No   No 

Reported  error  rate  <>=>>=>> 


Symbols: 

=  equal  to  ideal 

>  greater  than  ideal 

<  less  than  ideal 
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of  the  metasystem  of  organization,  people,  and  program  ma- 
terial involved  in  the  creation  and  maintenance  process" 
[  59,  60]. 

Feedback  is  tasic  to  the  process  since  the  system  and 
system  designers  are  considered  as  a  metasystem.  The  key  to 
good  feedback  is  intensive  use  over  time.  The  more  the 
software  is  used,  the  better  it  gets,  as  long  as  deficien- 
cies are  fed  back  into  the  maintenance  group  and  corrections 
are  made.  This  statement  holds  true  provided  that  the  main- 
tainers  introduce  fewer  errors  than  they  resolve.  Likewise, 
the  longer  it  is  used  the  less  the  probability  that  the  sys- 
tem contains  major  deficiencies.  In  analyzing  a  software 
development  system,  a  simple  beginning  would  be  as  shown  in 
figure  2.7.  When  pressure  is  exerted  to  provide  bigger  re- 
leases (later  versions  of  a  system  that  contain  enhancements 
and/or  corrections) ,  the  results  are  more  complexity,  re- 
duced quality,  and  growth  rate  limiting  factors.  Eventual- 
ly, releases  are  made  solely  for  restructuring/rewriting. 
At  this  point,  a  fission  effect  is  possible  where  excessive 
growth  leads  to  system  breakup. 

Various  published  papers  [61,  62]  have  discussed  the 
characteristics   and   dynamics   of   the   evolution  of  large 
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Figure  2.7.   Development  Release  Cycle 

programs,  with  the  most  significant  contribution  cf  research 
done  by  Lehman  and  Belady  [63,  64].  Their  efforts  were  di- 
rected at  understanding  the  dynamics  of  the  software  life- 
cycle,  thereby  creating  an  enhanced  environment  of  manageri- 
al awareness  and  an  understanding  cf  system  behavior.  Long 
term  unpredictability  of  the  system  development  and  mainte- 
nance processes  have  been  attributed  to  the  human  interface. 
However,  it  has  been  found  that  measures  of  system  activity 
such  as  number  of  modules  handled,  inter-release  time,  and 
total   number  cf   modules   in  the   system,   show  an   unusual 
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regularity.  Sines  this  regularity  could  not  be  attributed 
to  management  decisions,  Lehman  and  Belady  have  tried  to 
analyze  it  through  the  use  of  evolution  dynamics.  By  de- 
scribing the  environment  of  program  creation  and  maintenance 
in  terms  of  regularities,  trends,  and  patterns,  they  have 
proposed  laws  governing  the  evolution  dynamics  (table  II) . 

Features  of  these  evolutionary  trends  were  further  sup- 
ported in  a  more  recent  study  by  Leintz  knd  Swanson  [65]. 
Analysis  of  data  obtained  from  an  extensive  survey  indicated 
that  the  magnitude  of  a  maintenance  effort  can  be  explained 
by  the  combined  efforts  of  four  variables:  system  age,  sys- 
tem size,  relative  amount  cf  routine  debugging,  and  the  re- 
lative experience  of  the  maintainers.  The  relationships  of 
these  variables  were  modeled  as  shown  in  figure  2.8.  Amount 
of  maintenance  effort,  the  dependent  variable,  is  seen  to  be 
influenced  through  five  other  causal  paths  involving  four 
variables.  Each  causal  path  is  initiated  from  the  indepen- 
dent variable,  system  age. 

E.   PRODUCTIVITY 

Productivity  is  often  considered  a  measure  of  the  trans- 
formation of  meaningful  and  controllable  units  of  input  to 
meaningful  and  controllable  units  of  output.  The  guestion  of 


38 


TABLE  II 
Laws  of  Evolution  Dynamics 


CONTINUING  CHANGE 

A  program  that  is  used  and  that,  as  an  implementation 
of  its  specification,  reflects  some  other  reality, 
undergoes  continuing  change  or  becomes  progressively 
less  useful.  The  change  or  decay  process  continues 
until  it  is  judged  more  cost  effective  to  replace  the 
program  with  a  recreated  version. 

INCREASING  COMPLEXITY 

As  an  evolving  program  is  continuously  changed,  its 
complexity,  reflecting  deteriorat ina  sturcture,  in- 
creases unless  work  is  done  to  maintain  or  reduce  it. 

THE  FUNDAMENTAL  LAI 

(OF  PROGRAM  EVOLUTION) 

Program  evclution  is  subject  to  a  dynamics  which 
makes  the  programming  process,  and  hence  measures  of 
global  project  and  system  attributes,  self-regulating 
with  statistically   determinable   trends/invariances. 

CONSERVATION  OF  ORGANIZATION  STABILITY 

(INVARIANT  WCRK  RATED) 

The  global  activity  rate  in  a  project  supporting  an 
evolving  program  is  statistically  invariant. 

CONSERVATION  OF  FAMILIARITY 

(PERCEIVED  COMPLEXITY) 

The  release  content  (changes,   additions,  deletions) 
of  the  successive  releases  of  an  evolving  program  is 
statistically  invariant. 


quality  must  be  understood  in  all  measures  of  productivity, 
if  they  are  to  have  meaning.  It  is  far  easier  to  be  more 
productive  when  producing  thrcwaway  products  than  it  is  when 
producing  high  quality  output. 
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Figure  2.8.   Casual  Paths  of  Maintenance  Effort 

If  software  is  sized  in  terms  of  a  product  measure  such 
as  the  number  of  instructions  or  modules,  then  the  assumed 
personnel  productivity  against  those  measures  is  a  key  vari- 
ant in  the  estimate.  Since  producing  software  is  a  very 
labor  intensive  activity,  consuming  greater  than  eighty  five 
percent  of  the  resources  allocated  for  software  development 
f66],  an  essential  ingredient  for  arriving  at  an  accurate 
cost  estimate  of  the  software  lies  in  personnel  productivi- 
ty. Generation  cf  software  is  creative  and,  therefore,  a 
wide  variance  across  personnel  productivity  can  be  expected. 
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3udget  estimations  required  fcr  software  development 
have  led  to  an  abundance  of  research  exploring  the  topic  of 
programming  productivity  [67,  68,  69]  Traditional  measures 
of  software  productivity  have  included: 

1)  dollars  per  defect, 

2)  lines  of  code  (LOC)  per  person-month  (PM)  , 

3)  dollars  per  LOC, 

4)  dollars  per  PM,  and 

5)  complexity  branch  per  1000  LOC. 

Maintenance  researchers  pose  the  yet  unanswered  ques- 
tion: Can  the  same  criteria  be  applied  for  productivity 
during  the  maintenance  phase?  Within  a  maintenance  scenar- 
io, module  constituents  of  a  software  application  can  be 
categorized  as  new,  modified,  retained,  and  converted  (fig- 
ure 2.9).  New  segments  consist  of  entirely  new  code.  Modi- 
fied segments  are  composed  of  changed  code  and  the  unchanged 
code  that  may  be  affected  by  the  changed  code.  Retained 
code  consists  of  previously  developed  and  tested  segments 
that  will  be  integrated  into  the  software  products  without 
being  modified.  Converted  code  is  existing  code  converted 
to  another  language.  Each  of  the  categories  of  code,  when 
related  to  a  specific  product,  may  produce  a  unique  produc- 
tivity rate. 
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Figure  2.9.   Categories  of  Program  code 

Factors  which  influence  productivity  have  been  widely 
researched.  Data  collected  from  sixty  projects  by  "rfalston 
and  Felix  showed  that  significant  relationships  existed 
between  productivity  (SLOC)  and  the  ratio  of  developed  code 
to  the  sum  of  original  (or  reused)  code  plus  the  developed 
code  [70].  The  resulting  plot  shown  in  figure  2.10  suggests 
that  productivity  is  highest  when  there  is  no  original  or 
reused  code,  that  is,  when  all  the  cede  is  developed  from 
the  inception  of  the  project.  As  the  percentage  of  reused 
code  grows,  the  expected  productivity  decreases. 
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Figure  2.10.   Productivity  -  Reused  Code  Relationship 

Recent  investigations  done  by  Swanson  and  Leintz,  re- 
vealed that  while  productivity  techniques  have  teen  exten- 
sively discussed,  few  systemic  studies  of  benefits  in  the 
maintenance  phase  have  been  conducted  [71].  Figure  2.11 
shews  some,  but  not  all,  cf  the  factors  commonly  cited  as 
indices  of  productivity. 

Maintenance  costs  must  be  viewed  collectively  with  pro- 
ductivity.  To  dc  less   is  to   focus   on  only   part   of  the 
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Figure  2.11.   Productivity  Determinants 

issue.  It  could  be  a  misleading  focus  if  management  dic- 
tates policies  that  result  in  high  productivity  during  de- 
velopment work  tut  adversely  affect  the  productivity  of 
post-delivery  maintenance.  If  the  productivity  is  negative- 
ly affected   because  of  internal   problems  prior  to  delivery 
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or  reduced  quality  when  in  use,  then  costs  will  increase  and 
affect  the  potential  to  complete  other  projects. 

F.   COMPLEXITY  METRICS 

Quantitative  metrics  which  assess  the  complexity  of 
software  continue  to  attract  a  high  degree  of  interest. 
These  metrics  are  assumed  to  be  valuable  aids  in  determining 
the  quality  of  software.  A  collection  of  such  metrics  which 
assess  numerous  factors  that  constitute  this  nebulous  "soft- 
ware quality"  have  been  proposed  [72,  73].  Such  factors  in- 
clude reliability,  portability,  maintainability,  and  myriad 
other  xxx-abilities. 

Potential  uses  for  measures  which  assess  these  various 
factors  are  manifold.  Importance  of  metric  relationships 
lies  in  the  following  areas: 

1)  As  feedback  to  programmers,  they  can  be  used  during  de- 
velooment  to  indicate  potential  problems  with  developed 
code' [74].  A  design  is  evaluated  with  the  metric  rela- 
tionships in  mind.  If  it  appears  that  this  design  falls 
outside  of  the  metric  bounds,  then  another  design  must 
be  contemplated. 

2)  In  guiding  software  testing,  McCabe's  cyclomatic  number 
has  been  proposed  as  a  means  of  assessing  the  computa- 
tional complexity  of  the  software  testing  problem  [75]. 
Other  metrics  which  index  the  quality  or  complexity  of 
software  may  help  identify  modules  or  subroutines  wnich 
are  likely  to  be  most  error-infested. 

3)  If  one  of  a  combination  of  metrics  can  be  empirically 
related  to  the  difficulty  programmers  experience,  then 
more  accurate  estimation  can  be  made  of  the  manpower 
that  will  be  necessary  during  maintenance. 
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In  using  these  metrics,  it  is  important  to  distinguish 
between  the  ccmp utational  and  psychological  complexity  of 
software,  since  reasons  for  assessing  them  differ.  Compura- 
tional  complexity  refers  to  "the  quantitative  aspects  of  the 
solutions  to  computational  problems"  [76]  such  as  comparing 
the  efficiency  of  alternate  algorithmic  solutions.  To  il- 
lustrate, as  the  number  of  distinct  control  paths  through  a 
program  increases,  the  computational  complexity  may  in- 
crease. Psychological  complexity  refers  to  characteristics 
of  software  which  make  it  difficult  to  understand  and  work, 
with.  Psychological  complexity  can  then  be  thought  of  as 
assessing  human  performance  on  programming  tasks.  Subse- 
quent sections  will  discuss  currently  used  metrics  that  have 
been  coupled  with  the  maintenance  effort  in  an  attempt  to 
predict  programmer  effort  required  to  complete  a  specific 
maintenance  task. 

1  •   Ha 1st ead^s  2 

During  the  last  few  years  research  aimed  at  the  de- 
velopment of  a  "software  science"  has  supported  the  conten- 
tion that  there  may  be  simple  theoretical  explanation  for 
the  structural  characteristics  of  many  computer  programs  and 
that  there  is   a  strong   quantitative  relationship   between 
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these  characteristics  and  the  effort  required  to  write  pro- 
grams [77,  78,  79].  Based  on  the  theory  of  software  sci- 
ence, five  entities  of  an  algorithm  expressed  in  a  language 
are  measureable: 

n   =  number  of  distinct  operators, 

n   =  number  of  distinct  operands, 
2 

N   =  total  number  of  operators, 

N   =  total  number  of  operands,  and 
2 

n   =  number  of  input/output  parameters  for  the 
algorithm. 

From  these  measurements,  some  defined  properties  for  pro- 
grams can  be  calculated:  length  (N) ,  vocabulary  (n)  ,  volume 
(V)  ,  and  program  level  (L)  .  [80] 

Using  the  simple  relationships  between  these  metrics 
and  the  effort  (E)  required  by  a  programmer,  Halstead  ar- 
rived at  an  expression  of  effort  (total  number  of  elementary 
mental  discriminations)  to  generate  a  given  program  where 

n  N  (N   +  N  )  log  (n   ♦  n   ) 
V      12   1     2      2   1     2 
E  -  -  - (2.5) 

L  2n 

2 

3y  applying  the  Stroud  number,  which  is  the  number 
of  eleaentry  pieces  of  data  that  a  person  can  mentally  sep- 
arate per  second  (S) ,  a  dimension  of  time  is  introduced  to 
the  effort  equation: 
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E      V 
T  =  -   = (2.6) 

S      SL  l    ' 

where  T  indicates  the  estimated  time  fcr  programming.  Ex- 
cept for  the  Stroud  number,  all  parameters  on  the  right  side 
of  the  equation  are  directly  measureable  for  any  implementa- 
tion cf  an  algorithm.  Research  methods  using  calculated  T 
values  have  shewn  that  a  strong  correlation  exists  with  the 
actual  tiae  measurements  in  the  absence  of  certain  "impuri- 
ties" which  correspond  to  common  undesirable  programming 
practices  such  as  unstructured  code,  low  module  cohesive- 
ness,  high  module  coupling,  etc.  [81]. 
2  .   Mc Cabers  v (G) 

More  recently,  T.  McCabe  [82]  developed  a  complexity 
definition  based  on  the  decision  structure  of  a  program. 
McCabe' s  metric  is  the  classical  graph  theory  cyclomatic 
number  v  (G)  defined  as: 

v  (G)  =  number  of  edges  -  number  of  nodes 

♦  2  (number  or  connected  components). 

Two  simpler   metheds  cf  calculating   v (G)   are   presented  by 

McCabe:    the  number  of  predicate  nodes  plus  1  or  the  number 

of  regions  computed  from  a  planar  graph  of  the  control  flow. 

Literally,    this  complexity   metric  counts   control 

path  segments   which,   when  combined,   will  generate   every 
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possible  path  through  the  program.  Since  additional  control 
paths  could  make  a  program  more  difficult  to  understand,  the 
number  of  basic  paths  indexed  by  this  metric  may  also  relate 
to  mental  difficulty  of  a  programming  task. 

G.   ERROR  PREDICTION 

If  managers  knew  how  a  program  behaved  for  every  con- 
ceivable ccmbination  cf  inputs  and  could  accurately  predict 
all  future  input  combinations,  then  they  would  knew  precise- 
ly how  many  errors  are  in  that  program  and  could  predict  at 
which  point  in  time  that  the  program  would  next  fail.  As  a 
result,  it  would  be  fairly  simple  to  program  resources  for 
software  maintenance.  The  only  real  decision,  then,  would  be 
whether  the  annoyance  from  the  error  was  worth  the  effort  to 
eliminate  it.  Because  this  ideal  situation  is  not  a  realis- 
tic representation  of  the  world,  except  in  the  most  trivial 
programs,  it  would  ce  a  great  aid  to  managers  to  have  a 
method  to  predict  residual  errors  with  a  reasonable  degree 
of  certainty.  This  capability  would  arm  them  with  a  good 
guide  for  programming  the  amount  of  maintenance  effort  need- 
ed for  the  next  time  period. 

In  the  early  days  of  computing,  managers  obtained  rough 
estimates  of   the  number  of  errors   in  a  module   by  assuming 


49 


that  there  was  one  tug  in  every  sixty  lines  of  code  or 
perhaps  in  every  ere  hundred  lines  of  cede  depending  on  each 
manager1 s  optimism  and  experience  £83].  It  seems  to  be  a 
reasonable  assumption  that  there  is  a  better  way  to  predict 
residual  errors.  The  importance  of  error  detection  analysis 
has  been  recognized  in  the  past  few  years  and  many  studies 
have  addressed  this  problem.  [84,  85,  86,  87,  88,  89,  90, 
91]  An  important  objective  of  most  of  this  work  has  been 
to  develop  analytical  techniques  to  examine  the  error  phe- 
nomenon in  order  to  compute  or  predict  items  of  interest 
such  as  the  number  of  errors  detected  at  time  t,  the  pre- 
sumed number  of  remaining  errors  at  time  t,  and  the  software 
reliability  function.  (It  should  be  noted  that  none  of 
these  studies  deals  specifically  with  the  detection  or  the 
prediction  of  errors  during  the  maintenance  phase  of  the 
software  life-cycle.) 

One  would  expect  software  reliability  to  improve  with 
age  because  latent  bugs  are  detected  and  are  presumably  cor- 
rected. However,  there  are  exceptions  to  this  general  state- 
ment. Bugs  can  be  induced  into  programs  while  corrections 
are  being  made.  This  situation,  called  the  "ripple  effect", 
generally  happens  in  very  large   systems  like  0/S360  instead 
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of  small  systems  like  a  compiler  [92],  When  a  change  is 
made  in  module  'A'  it  affects  the  way  module  #B'  works.  The 
maintainer  has  neither  the  desire  to  change  another  module 
nor,  probably,  any  idea  that  his  change  would  affect  another 
module.  With  vast,  complex  systems  it  is  impossible  for  any 
person  to  know  all  of  the  ramifications  of  a  change.  Since 
most  operational  software  is  subject  to  enhancements  and 
changes  in  requirements  because  of  the  dynamic  environment 
in  which  it  is  run,  it  can  be  expected  that  bugs  will  be  in- 
duced with  the  new  code  and  that  other  modules  will  be  af- 
fected through  interfaces  with  the  new  modules.  In  the  long 
run  however,  it  appears  that  most  software  projects  follow 
the  predicted  process  and  have  fewer  errors  as  time  elapses 
[93].  Table  III  £94]  provides  data  to  support  this  phenome- 
non. Observe  the  great  variability  of  the  data  and  the  in- 
creased reliability  as  time  passes. 

Although  the  code  appears  to  become  more  reliable  as 
time  passes,  there  are  still  problems  with  error  prediction 
models.  Many  of  these  models  assume  a  constant  error  rate 
[95,  96,  97,  98,  99].  This  does  not  strike  one  as  being  a 
reasonable  assumption  on  three  accounts.  First,  the  failure 
rate  will   fluctuate  because  the   frequency  of   execution  of 
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TABLE  III 


Successive  Execution  Times  Between  Failures 


(Measured  in  seconds,  read  left  to  right  and  top  to  bottom.) 
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the  areas  cf  code  varies.  Some  areas  may  never  be  executed 
[  100].  As  an  example,  if  one  assumes  that  there  are  one 
hundred  bugs  in  a  program,  that  tne  failure  rate  is  fifty 
failures  a  week,  and  that  one  is  using  a  constant  error  rate 
prediction,  then  after  fifty  bugs  have  been  eliminated  the 
failure  rate  should  be  to  be  twenty-five  failures  per  week. 
If  the  bugs  are  eliminated  in  the  order  that  they  are  de- 
tected, the  first  fifty  tc  be  eliminated  would  be  in  the 
most  frequently  exercised  areas  of  code  and  the  observed 
failure  rate  would  be  less  than  twenty-five  per  week.  If, 
on  the  other  hand,  the  most  severe  errors  were  corrected 
first,  there  may  be  a  situation  where  there  are  several  an- 
noying but  non-critical  bugs  in  a  highly  exercised  portion 
of  code  and  the  observed  failure  rate  is  forty  failures  per 
week  despite  having  eliminated  fifty  bugs. 

Second,  according  to  Ottenstein  [101],  the  error  rate 
for  modules,  at  the  validation  and  integration  stage,  varies 
inversly  with  the  size  of  a  module.  This  theory  has  been 
corroberated  by  Motley  and  Brooks  [102].  Motley  and  Brooks 
feel  that  this  inverse  proportion  is  an  indication  that 
the   laraer  modules   were  not   as  fully  debugged   during  the 
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validation  and  integration  stages  and  would  go  into  The  op- 
erations and  maintenance  phases  with  a  greater  proportional 
amount  of  errors.  Ottenstein  explained  the  phenomenon  in 
just  the  opposite  manner.  She  feels  that  there  is  a  learn- 
ing and  retention  benefit  that  operates  with  large  modules 
and  thus  the  larger  modules  will  go  into  operations  and 
maintenance  with  a  smaller  proportional  amount  of  errors. 

k  third  reason  for  a  variable  rate  of  errors  at  the 
validation  and  integration  phase  is  also  proposed  by  Otten- 
stein  [103].  Earlier  developed  modules  are  more  fully  de- 
bugged in  the  initial  testing  because  at  that  period  in  the 
project  there  is  a  lot  of  time  and  money  to  do  the  job  cor- 
rectly. However,  modules  that  are  developed  near  the  end  of 
a  contract  appear  to  be  hastily  and  incompletely  debugged 
before  being  submitted  for  validation  because  both  time  and 
money  are  running  out.  The  authors  propose  a  corollary  to 
this  hypothesis.  The  more  over-budget  and  behind-schedule 
that  a  project  is  delivered,  the  higher  should  be  the  pre- 
diction of  errors  detected  in  the  maintenance  phase. 

2ven  if  a  manager  could  accurately  predict  the  number  of 
errors  that  will  be  detected  in  a  given  time  period,  there 
would  still  be  a  problem  in   scheduling  the  proper  amount  of 
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resources.  Different  types  of  errors  will  require  different 
amounts  of  effort  for  correction  because  they  are  of  differ- 
ent complexities. 

H.   CHAPTER  SUMMARY 

Numerous  software  topics  are  under  study  in  an  attempt 
to  uncover  explanations  for  the  phenomenology  of  the  soft- 
ware life-cycle.  Of  more  specific  concern  are  the  events 
which  lead  to  the  increased  expenditures  during  the  opera- 
tion and  maintenance  phase  of  the  software  project.  Indica- 
tions from  research  evidence  are  that  not  one  single  factor 
can  be  named  as  the  dominant  contributor  to  the  life-cycle 
maintenance  costs.  Instead,  a  multiplicity  of  factors  are 
cited  as  having  an  impact  on  the  total  system. 

Recognizing  the  futility  of  identifying  a  single  con- 
tributor, reseachers  have  resorted  to  finding  the  control 
elements  that  best  define  the  changes  that  occur  in  system 
characteristics.  With  a  continued  research  effort,  better 
understanding  and  increased  familiarity  of  these  system  con- 
trol elements  may  lead  to  positive  results  in  linking  sys- 
tem characteristics  with  maintenance  requirements. 
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III.   COST  ESTIMATION  OF  SOFTWARE  MAINTENANCE 

Coupling  the  rising  costs  of  computer  software  with  the 
relative  decline  in  computer  hardware  costs  would  indicate 
that  computer  software  acquisition  cost  and  maintenance  and 
operation  cost  (collectively  referred  to  as  software  life- 
cycle  costs)  constitute  the  greatest  share  of  the  data  pro- 
cessing budget.  Consequently,  predicting  future  software 
costs  for  both  existing  systems  (maintenance  and  operation 
costs)  and  new  development  is  of  increasing  concern  to 
management . 

The  phenomenology  of  the  software  development  and 
maintenance  process  is  not  definitively  known.  Research 
suggests  the  existence  of  a  fairly  clear  time-varying  pat- 
tern such  as  a  Rayleigh  curve  or  seme  ether  similiar  form. 
The  analysis  is  complicated  by  the  presence  of  "noise"  or 
stochastic  components.  Additionally,  the  observable  compo- 
nents (manpower,  cost,  time)  are  strongly  subjected  to  man- 
agement perturbation.  This  would  indicate  -hat  although  a 
system  has  a  characteristic  life-cycle  behavior,  if  that  be- 
havior is  not  known  to  managers  a  Eriori,  then  they  will 
respond  reactively  (non-optimally  with  time  lags)  to  system 
demands.    A  reasonable  basis  now   exists  for  expecting  that 
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an  adequate  phencmenological  description   may  arise  from  the 
following  sources: 

1)  statistical  mechanics; 

2)  information  theory  coupled   with  statistical  communica- 
tion theory; 

3)  diffusion  and  transport  theory.  [104] 

Tracking  of  costs  throughout  the  life-cycle  is  important 
because,  as  pointed  out  in  chapter  Two,  sixty  percent  of  the 
life-cycle  effort  is  consumed  during  the  operations  and 
maintenance  phass.  If  this  phase  is  treated  as  a  level-of- 
effort  task,  then  far  more  resources  than  necessary  for 
maintenance  are  used.  Given  a  fixed  manpower  or  budget 
constraint  (very  common  in  government) ,  less  than  optimal 
control  of  the  work  during  this  phase  increases  the  possi- 
bility of  maintenance  work  saturation  (i.e.  devoting  all  re- 
sources to  maintenance) .  This  situation  leaves  no  capability 
to  accomplish  additional  work. 

Within  the  scope  of  this  discussion,  three  types  of 
models  for  addressing  maintenance  cost  estimation  will  be 
considered: 

1)  software  cost   estimation  from   a  macroesti mating   view 
using  the  Ncrden-Rayleigh  curve  parameters; 

2)  software  cost   estimation  from   a  microestiaating   view 
using  a  work  breakdown  structure (WES)  methodology; 

3)  software  evolution  dynamics  using   system  complexity  as 
a  cost  monitor. 
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The  format  of  presentation  will  include  a  general  descrip- 
tion of  the  model  with  subsequent  application  of  the  model 
to  the  forecasting  of  costs  within  a  maintenance  scenario. 

A.   SOFTWARE  COS!  ESTIMATING  MODELS 

1  •   ?ulH§J2.L§  Soft  ware  Cost  Estimating  Model 
a.   Description 

This  model  attempts  to  provide  quantitative  an- 
swers to  the  questions  often  asked  by  managers  about  soft- 
ware projects.  These  questions  are  generally  concerned  with 
project  time  duration,  total  cost,  and  the  accuracy  of  the 
figures  presented.  Putnam's  [105]  methods  provide  estimates 
in  the  following  areas: 

1)  Total  life  cycle  effort  in  manyears; 

2)  Cost  for  the  project; 

3)  Peak  manpower  needed; 

4)  Manpower   needed  at  any  specific  time  or   phase  in  the 
project ; 

5)  Risk  and  variance  analysis  of  derived  estimates;  and 

6)  Linear  programming  (LP)  techniques  to  impose  real  world 
management  constraints. 

Putnam's  contribution  to  software  cost  estimat- 
ing was  to  apply  the  Rayleigh  curve  to  software  life-cycle 
manloading.    Using  the  techniques  based  upon  the  life-cycle 
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theory  developed  by  Norden,  Putnam  did  a  number  of  empiri- 
cal studies  and  found  that  the  software  life-cycle  exhibits 
a  rise  in  manpower  up  to  a  peak  and  then  a  trailing  off. 

Basically,  the  Putnam  model  obtains  estimates  of 
the  measure  of  work  in  man-years  and  of  the  total  develop- 
ment time  of  the  project.  Development  time  in  the  Putnam  mo- 
del is  defined  as  the  elapsed  time  on  the  project  up  to  the 
point  when  the  system  reaches  full  operational  capability, 
but  not  including  the  system  definition  and  functional 
design/specification  phases.  The  estimates  of  the  total  life 
cycle  in  man-years  and  the  development  time  are  then  used  to 
derive  an  equation  giving  the  ordinates  for  a  man-power  ex- 
penditure curve  for  a  specific  project.  A  yearly  dollar 
costing  can  then  be  computed  for  the  project  by  muitipying 
the  ordinates  cf  the  man-power  curve  at  each  year  by  the  av- 
erage cost/man-year  to  arrive  at  a  dollar  cost/year  and, 
subsequently,  at  a  tctal  dollar  cost  for  the  project.  Put- 
nam uses  the  Raleigh  eguation,  which  has  been  empirically 
determined  to  fit  the  project  manpower  loading  profile  for 
large  projects  and  to  best  represent  Norden's  model.  The 
most  popular  form  of  the  curve  is  the  derivative  form  and  is 
expressed  by: 
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2 

-at 
y»  =  2Kate  (3.  1) 

where 

y1  =  the  number  of  man-years  of  effort  expended  per 

year, 

K   =  the  total  number  of   man-years  required  during 

the  life  cycle  of  the  project, 

a   =  the  curve  shape  parameter, 

t   =  the  elapsed  time  in  years,  and 

e   =  the  exponential  function. 

With  the  assumption  that  the  shape  of  the  curve 

is  somehow   related  tc  both  the  difficulty  of   a  particular 

development  and  tc  the  skill  level  of  the   project  team,   a 

means  for   expressing  these  relationships   in  terms   of  Eay- 

leigh  curve  parameters  was  derived.   The  relationship  of  the 

parameter  a  to  development  time  (t  )  is: 

d 

2 
a  =  1/2t  (3.2) 

which,  when  substituted  into  the  derivative  form  of  the  Hay- 

leiqh  curve,  results  in  the  following  equation: 

2     2 
-(t  /2t_  ) 
2  a 

y«  =  K/t   te  (3.3) 

d 
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To  use  the  above   equation,   estimates   must  be 

found  for   the  total   life  cycle   in  man-years  (K) ,   and  the 

development  time  (t  ) .   Virtually  every   parametric  software 

d 

cost  model  is  based  on  an  estimate  of  computer  program  size, 
measured  in  either  source  statements  or  object  code  instruc- 
tions. Putnam  uses  source  statements  because  that  is  what 
programmers  produce.  Likewise,  it  simplifies  the  mathemati- 
cal computations  because  compiler  efficiencies  are  not  con- 
sidered. The  relationship  that  is  used  by  Futnam  to  equate 
source  statements  to  development  time  and  project  effort  is 
given  by  the  following  equation: 

(V3) 

Ss  =  Ck*K      t  (3. £4) 

d 

where 

Ss  =  delivered  source  lines  of  code,  and 
Ck  =  state-of-technology  constant. 

Within  the  model,  estimating  program  size  is 
viewed  as  an  iterative  process  that  should  be  recomputed 
several  times  during  the  system  definition  and  functional 
design/specification  phases  in  the  software  life  cycle.  The 
first  estimate  is  done  at  project  conception  and  can  be  lit- 
tle more  than  a  best  guess   used  to  establish  basic  economic 
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feasibility  based  on  past  software  projects  and  expert  opin- 
ion. As  more  knowledge  is  gained  about  the  project,  indivi- 
dual segments  of  the  system  are  estimated  seperately  and 
then  totaled  to  give  a  more  accurate  estimate  of  the  expect- 
ed size.  Also,  standard  deviations  and  confidence  intervals 
are  derived  from  statistical  methods  that  use  best  and  worst 
case  estimates. 

To  determine  the  technology  constant,  data  from 
past  software  projects  must  be  inserted  into  the  software 
equation  (3.4)  tc  derive  the  unknown  variable  Ck.  It  should 
be  noted  that  Ck  is  initially  very  difficult  to  determine 
but  should  remain  consistent  for  similar  projects  within  a 
specific   organization.   After  the   parameters  Ss  and  Ck  are 

determined,  various  values  of  t   and/or  K  may  be  substituted 

d 

into  the  software  equation  to  produce  a  parametric  graph 
showing  size  versus  effort  and  time  (figure  3.1). 

A  constraint  line  determined  by  management  and 
representing  a  difficulty  gradient  for  certain  types  of  pro- 
jects is  then  superimposed  on  the  graph.  Values  tnat  fall 
below  this  line  are  determined  to  be  infeasible  for  software 
development . 

After  values   and  ranges  are  found  for  t   and  k, 

d 
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Figure   3.1.      Size   vs.    Effort    and  Time   Relationship 

dollar  costs  for  the  project  may  be  computed  by  multiplying 
plying  an  average  labor  rate  per  man-year  by  an  expected 
value  of  man-years  tc  derive  an  estimated  total  cost  for  a 
project.  A  variance  estimate  for  dollar  costs  may  be  ob- 
tained in  a  similar  manner  from  the  variance  of  man-years. 
While  this  model  recognizes  that  real  world  managerial 
constraints  exist,  they  are  not  explicitly  addressed.  In- 
stead it  is  reccmmended  that  linear  programming  techniques 
should   be      used      to    account   for      everyday      concerns      such    as 
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contract  deadlines,   cost  ceilings,  and  hiring  practices  and 
capabilities. 

b.   Application  to  Maintenance  Costing 

Putnam1 s  model  takes  a  macro  approach  to  answer- 
ing the  questions  mcst  often  asked  by  managers  concerning 
the  areas  of  time,  effort,  and  cost.  According  to  relation- 
ships determined  empirically,  an  overall  estimate  of  man 
power  is  obtained  and  subsequently  allocated  among  the 
different  phases.  To  determine  the  risk  involved  in  the  es- 
timation, statistical  methods  are  used  which  give  the  manag- 
er a  'feel1  for  the  accuracy  of  the  data  presented  to  him. 

As  wcrk  proceeds  during  the  life-cycle,  uncer- 
tainty about  the  management  parameters  decrease.  In  order 
to  follow  and  track  the  time-varying  behavior  of  a  software 
system,  empirical  data  must  be  collected  and  plotted  to  show 
the  current  labor  force  for  any  given  time  (figure  3.2). 
Using  this  data  stream,  time  series  analysis  can  be  done. 
By  turning  the  characteristic  Rayleigh  behavior  into  a 
straight  line,  the  actual  manpower  data  may  fce  fitted  to  get 
a  revised  estimate  of  future  resource  consumption. 

The  linear  form  of  the  Rayleigh-Norden  curve  is 
illustrated  in  figure  3.3.  This  form  may  be  obtained  by  di- 
viding equation  3.3  by  t  and  taking  the  natural  logorithm  of 
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Figure  3.2.   Typical  Plotting  Structure 


the  result.   This  yields 


2   2  2 

Ln(y'/t)  =  (~1/2t  )t   +  Ln(K/t   ) 

d  d 


(3.5) 


which  fits  the  familiar  linear  form  y  =  mx  ♦  b. 

Actual  data  is  set  up  in  a  table  form  with  addi- 
tional calculated  data  points  that  are  needed  for  the  cor- 
responding plot.  Hypothetical  data  from  Table  IV  is  plot- 
ted in  figure  3.3  with  the  best  straight  line  fitted  to  the 
data  points  (determined  by  eye  or  calculation). 

From  this  plot,  Hayleigh  parameters  can  be  cal- 
culated.  The  slcpe  can  be  used  to  compute   development  time 

2 
(t  ) ,   while  the   intercept  (K/t  ) ,   given  the   value  of  t 
d  d  d 

just  obtained,  yields  the  value  of  total  effort,  K.  Calcu- 
lations for  determining  these  values  are  listed  with  the 
figure. 
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TABLE  IV 


Hypotheical  Project  Data 


r 


y'/t 


Ln(yVt) 


1 

68 

2 

70 

3 

106 

4 

118 

68.0 
35.0 
35.33 
29.50 


1 

4 

9 

16 


4.22 
3.55 
3.56 
3.38 


Projected  management  estimates  can  be  calculated 
by  extending  the  line  to  subsequent  year  points  (figure 
3.4).  Continuing  with  the  same  example  data,  future  man- 
loading  predictions  are  made  by  applying  the  sequence  of 
equations  contained  in  figure  3.4. 

Similiarly,  resource  estimation  for  additional 
outyears  may  be  computed.  As  mentioned  earlier,  this  model 
is  an  iterative  procedure.  Each  year  actual  project  data  is 
added  to  the  table.  The  data  points  are  replotted  and  the 
best  fit  straight  line  is  again  determined.  Mew  values  for 
the  slope  and  intercept  are  found  and  projections  are  then 
aade  based  on  these  new  values. 


66 


Ln(y»/t) 

5 
4 
3 
2 
1 


x   =    22 


y    =   -1 


0 S TO IS "2U 2S UT' 


2  2 

t         (time   ) 


Slope  Calculations 

y  -7  - 1 

Slope    = =      —   =      

x  22  2 

2t 
d 


take  reciprocals. 


=  m 


t    =22 
d 


t    =11 

d 


=   3.32  years 


Intercept  calculations 
I  =  4.  0  =  Ln  (K/t   )  =  b 


Ln(K/t      ) 
d 
e  =   4.0 


K/t  =      54.6 

d 


54.6    t 


K       =       54.6    *    11 


K      =      601    tuanyears 


Figure   3.3.      Fitting   the   Best   Straight    Line 
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Ln(y«/t) 

5 
14 

3 

2 


b  5  KJ 15 2U 25 TO 

2  2 

t         (time   ) 

Projection _f or   year_5 
t   «~"5   years 

Ln(y'/t)    =    2.85 

2.85 
y'/5   =    e 

2    85 
y»    =    s  (5)     =    17.29    (5) 

y*   =  36  people  (manyear/year) 
5 

Figure  3.4.   Line  Extension  and  Prediction 

2«   A£J2  Macrcestimating  Model 
a.   Description 

Realizing  that  there  was  a  need  for  a  simple/ 
effective,  reasonably  accurate  procedure  for  estimating  and 
controlling  resources,  Army  Headquarters  analysts  produced  a 
comprehensive  macroestimating  procedure  for  allocating  the 
appropriate  manpower  coamitaient  to   an  application  system  at 
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any  point  in  the  system  life  cycle  [106].  The  procedure 
enables  users  tc  forecast  the  size  of  a  new  application 
software  project  and  suggests  the  manlcading  necessary  to 
accomplish  the  project  workload. 

Some  functional  estimators  for  the  project  man- 
ager include: 

1)  optimum  man-loading  over  life-cycle; 

2)  total  manpower  over  life-cycle; 

3)  cost  per  year; 

4)  risk  prcfiles;and 

5)  scope  of  applicability. 

Initial  analysis  of  all  United  States  Army  Com- 
puter Systems  Command  (USACSC)  systems  yielded  a  database 
from  which  statistics  have  been  derived  that  permit  estab- 
lishment of  control  limits  on  resource  allocation  at  any 
point  in  the  life-cycle  of  a  system.  Additionally,  numeri- 
cal correlation  points  between  effort/unit  time  and  normal- 
ized time  were  established  for  system  development  mile- 
stones. Using  these  points,  the  project  manager  can  plot 
the  project  life-cycle  profile  of  a  software  development  ef- 
fort in  terms  of  the  time  that  various  milestones  should  be 
reached  and  the  level  of  resources  (manpower)  that  should  be 
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applied  to  the  system  development  at  those  points  (figure 
3.5)  . 

Excursions  outside  statistically  determined  control  limits 
shown  in  figure  3.5  should  trigger  the  action  officer  to 
take  corrective  action. 

Using  the  mathematical  relationship  developed  by 
Norden, 

2 

-at 
y«  =  2Kate  (3.1) 

step-by-step  procedures  were  developed  for  estimating  system 

variables  for  the  following  cases. 

( 1 )    Case  I :    Sy_st e m  already  un de r  development 

(resources  budgeted) .   Osing  budget  data,  the  maximum  level 

of  manpower  (y*    )  and  the  number  of  years  to  reach  maximum 
max 

effort  (t     )  is  determined.  Rather  than  compute  the  values 

y 

max 
for  outyear  manpower  loading.  Table  V  is  used  to  compute  the 

values  of  j1  for  the  appropriate  t     .   By  multiplying  any 

max 
antry  opposite  its  time  period  by  K,   the  appropriate  number 

of  manyears  are  obtained.  The  units  of  K  and  t  will  deter- 
mine the  demensicns. 


70 


MY/YB 


Design  Cert 
S.I.T. 
P.S.T. 


Y'max   -♦- 


|  j  Extension 


I 


I  i  i 


23  y'max 


START 
0 


Y1  max 
1 

NORMALIZED  TIME  (t/t 


tMaint 


DESIGN  CERTIFICATION 
first 
expected 

last 


0.235 


SYSTEMS    INTEGRATION    TEST 

first  0.550 

expected 

last 

PROTOTYPE  EVALUAIION  TEST 

first  0.613 

expected 

last 


EXTENSION 

first 

expected 

last 

MAINTENANCE 
first 
expected 
last 


0.613 


2 .  096 


0.4  33 


0.660 


0.800 


0.930 


2.38 


Y'max 


0.618 


0.76  8 


0.990 


1.25  0 


2.853 


2.38 
) 


NOTE    1:      First   and   last   are  at    five    percent    probability   lev- 
el-.i.e.    there   is    a  ninety    percent    probability   tha 
t/tymax    will    lie    between   first      and  last   for    a   par' 
ticular    milestone   event.      If   net,    ask   questions. 

NOTE   2:      Tabular   entries   are  in   normalized   time    units. 


Figure   3.5,      Milestones   Applied   to   Project    Profile 
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TABLE    V 
Ordinates   for  Manpower  Function 


£ 

I 
y* max  | 

1 

2 

3 

4 

5 

6 

7 

0| 

a   1 

.50 

.1250 

.0556 

.0310 

.0200 

.0139 

.0120  j 

1 1 

.60653 

.22062 

.10510 

.06057 

.03  9  20 

.02739 

.020201 

2| 

.27067 

.30326 

.  17794 

. 1  1031 

.07384 

.05255 

.309181 

3| 

.03332 

.24349 

.20217 

.14153 

.10023 

.07354 

.055851 

4| 

.00134 

. 13533 

.  18271 

.15163 

.  11618 

.08897 

.069331 

5| 

.00001 

.05492 

.13852 

.14307 

.  12130 

.09814 

.079061 

6| 

.01666 

.09022 

.12174 

.11682 

. 10108 

.084801 

7| 

.00382 

.  05 1 1 2 

.0  9461 

.10508 

.09845 

.086641 

Q\ 

.00067 

.02539 

.06766 

.08897 

.09135 

.08497| 

9| 

.00009 

.01110 

.04475 

.07124 

.08116 

.080361 

10| 

.00000 

.00429 

.02746 

.05413 

.06926 

.073561 

11 

.00000 

.00147 

.0  1567 

.03912 

.05691 

.065301 

12| 

.00044 

.00833 

.02694 

.04511 

.056341 

13| 

.00012 

.00413 

.01770 

.03453 

.047291 

14  j 

.00002 

.00191 

.01 111 

.02556 

.038661 

15 

.00000 

.00082 

.00666 

.08130 

.030811 

16) 

.00000 

.00033 

.00382 

.01269 

.023951 

17 

.00012 

.00210 

.00853 

. 01 817  J 

18j 

.00004 

.001  10 

.00555 

. 01346| 

19 

.C0001 

.00055 

.00350 

. 00974J 

20  | 

.00000 

.00026 

.00214 

.006391 

(2)  Case  II:  New  sjstei  (no  resource  data)  . 
Total  man- years  of  effort  and  peak  time  for  manpower  loading 
is  estimated  using  Bayes*  theorem.  [107]  Based  en  empirical 
data  from  internal  systems,  a  probability  versus  K  density 
function  was  derived  without  regard  to  type  of  system. 
Further  analysis  determined  frequency  of  system  type  and 
probability  of  occurence  of  each  type.  Using  estimates 
based  on  past  OSACSC  experiences  (the  average  K  value  for 
all  systems  under  development  and  average  K  for  the  func- 
tional type  of  system) ,  initial  estimates  for  a  new  new  de- 
velopment are  calculated  from  regression  graphs.  Then,  by 
applying  Bayes*  theorem  tc  average  these  individual  esti- 
mates in  the  weighted  probability  sense  yields  a  better  es- 
timate of  K  with  a  smaller  standard  deviation  (i.e.  better 
confidence  in  the  estimate)  .  To  improve  estimates  and  re- 
duce uncertainty,  Bayes1  theorem  is  sucessively  applied, 
b.   Application  to  Maintenance  Costing 

tJSACSC  empirically  determined  that   ail  of  their 
systems  reached  a  steady  level  of  effort  (maintenance  level) 
on  the   average  of  2.38   times  the   amount  of  time   that  was 
used  to  reach  maximum  effort.    This  relationship  can  be  ex- 
pressed as: 
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t  =    2.38t  (3.6) 

maint  y» 

max 

In   applying   this    equation,      a   system,      with    maximum   level   of 

effort   reached   at   year   three,      would  reach   a   steady  state   at 

7.14    years . 

The  level   of  effort  associated  with  the  steady 

state  maintenance  phase  was  empirically  determined  by  USACSC 

to  be   twenty-three  percent  of  y'       with  a  ninty  percent 

max 

confidence    interval   from      eight    percent   to   thirty-eight   per- 
cent  of   y*         .      At   that      point      in    the      project      life-cycle, 
max 

when      2.38t  (twenty-three      percent   of    y*         )    is   reach- 

y 

max  max 

ed,    using  numbers   generated  from  the  manpower  equation 

(3.1)  should  be  discontinued  and  a  constant   level  of  effort 

of  twenty-three   percent  of  y*  should  be  used  until   the 

max 

system  is  replaced.  Figure  3.6  shows  a  generalized 
control-limit  envelope  of  a  ninety  percent  confidence  inter- 
val for  the  resource  level. 
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Figure   3.6,      System  Resource-Control  Limits 


B.       SOFTWARE    EVOLUTION    MODEL 
1 .      Lehman-Belady    Model 
a.       Description 

There  have  teen  several  attempts  made  to  assess 
resource  ailocaticn  to  achieve  the  repair  or  modification 
required    for      a   single   release,      which    is   a    new    version   of   a 
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system.  A  variety  of  data  has  been  collected  relating  to 
module  handle  rate  and  release  interval.  Based  on  experi- 
ence in  dealing  with  different  environments,  it  has  been 
suggested  that  development  and  maintenance  trends  exist  giv- 
ing rise  to  complexity  measures.  These  measures,  in  turn, 
can  be  determined  by  the  average  number  of  old  module  han- 
dlings per  new  module  and  per  fault  fix,  respectively. 

As  systems  evolve  over  a  series  of  releases,  the 
ratio  of  changed  modules  to  the  total  number  of  modules  have 
been  found  to  mcnotonically  increase  and  approach  unity. 
This  ratio  is  an  observed  and  directly  measurable  quantity 
which  describes  the  system^  property  of  resistance  to 
change.  Of  importance  is  the  indication  that  the  number  of 
modules  involved  in  a  system  modification  is  likely  to  be 
proportional  to  the  effort  spent.  [108,  109] 

Belady  and  Lehman  proposed  a  model  in  which  ac- 
tivity is  of  three  kinds:  progressive  (E) ,  antigressive  (A) , 
and  additional  work  related  to  system  complexity  (C) .  It 
was  hypothesized  that  a  balanced  budget  (B)  implies  that  at 
any  time 

B  =  P  +  A  ♦  C.  (3.7) 
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Although  simple,  the  model  captures  two  important  aspects  of 
evolution  dynamics;  the  sharing  of  the  resources  between 
progressive  and  antigressive  effort  (where  both  A  and  C  are 
considered  antigressive)  and  the  absorption  of  total  budget 
and  further  growth  limitation  by  the  inevitable  rise  in  the 
cost  of  complexity. 

Increase  of  C  activity  is  hypothesised  to  stem 
from  neglect  of  A  activity.  Removal  of  resulting  cumulative 
neglect  can  be  accomplished  only  by  a  temporary  increase  in 
A.  If  the  total  budget,  B  is  limited,  the  result  is  a  tem- 
porary decrease  in  progressive  activity,  P.  It  is  assumed 
that  B,  P,  A,  and  C  can  te  measured  in  cost  per  unit  time. 
The  cost  function  is  expressed  in  the  following  fashion: 

Cost(t)  =  f  ^(1  -  m)KP  (r)  dr  (3.8) 

0J 

where 

KP  =  inherent  A  activity  required   for  each  unit  of 

P  activity  to  prevent  complexity  growth; 

m   =  management  factor,  the  fraction  of  KP  actually 

dedicated  by  management  to  A  activity  (0<m<1) ; 

and 

7"  =  a  time  constant. 
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b.   Application  to  Maintenance  Costing 

Preliminary  analysis  and  simulation  have  been 
carried  out  using  a  non-linear  differential  equation  model 
of  evolution  dynamics.  It  has  been  found  that  the  model  is 
capable  of  reproducing  some  important  phenomena  observed  in 
data  that  can  be  related  to  observed  characteristics  of  the 
system. 

In  figure  3.7,  the  simulation  shows  that  the 
code  production  rate  (the  progressive  element)  increases  to 
a  maximum  of  about  225  modules  per  year.  At  the  end  of  the 
first  year,  the  complexity  has  increased  to  the  point  where 
such  a  production  rate  cannot  be  sustained  with  the  budget 
available,  since  an  increasing  resource  demand  is  being  made 
by  A  and  C  activity.  A  balanced  budget  requires  a  reduction 
in  P  activity,  which  later  leads  to  a  reduction  in  A  activi- 
ty. By  year  six,  the  system  has  reached  its  limiting  size 
with  the  resources  available. 

Although  results  seem  promising,  a  great  deal  of 
work  must  be  done  before  practical  results  in  the  form  of  an 
accurate  predictive  model  can  be  achieved.  From  figure  3.7, 
it  would  s^em  apparent  that  application  of  control  theory 
to  modules  developed  earlier  may  result  in  a  substantial 
payoff  in  financial  terms. 
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Figure  3.7. 
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2.   Parr  Model 

a.   Description 

Putnam  and  Norden  have  prepared  a  Rayleign  curve 
model  for  the  rate  at  which  resources  are  consumed  by  soft- 
ware engineering  projects.  One  of  the  model's  main  assump- 
tions is  that  the  initially  rising  work  rate  is  due  to  a 
linear  learning  curve  governing  the  "skill"  available  for 
solving  problems  at  time  t.  This  assumption  is  guestionable 
because  a  linear  learning  curve  is  not  theoretically  sup- 
ported, and  the  skill  available  on  a  project  depends  on  the 
resources  which  have  been  applied  to  it  [110].    Thus,   this 
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assumption  confuses  intrinsic  constraints  on  the  rate  at 
which  software  can  be  produced  with  managements  economical- 
ly governed  choices  on  how  to  respond  to  these  constraints. 

Parr  asserts  that  the  rate  of  progress  on  a 
software  project  is  primarily  determined  by  dependencies 
among  the  problems  which  must  be  solved.  Some  problems  can 
be  solved  in  parallel  whereas  others  can  only  be  handled  se- 
quentially. Let  H(t)  be  the  number  of  problems  which  have 
been  solved  at  time  t  and  V  (t)  be  the  number  of  visible  un- 
solved problems  at  time  t  which  can  be  solved  (i.e.,  all 
earlier  required  problems  solved) .  When  a  problem  is  solved, 
w  (t)  increases  by  1;  V  (t)  ,  however,  may  increase  or  decrease 
depending  on  whether  or  net  the  problem  solved  makes  new 
problems  invisible/solvable.  It  is  reasonable  to  assume 
that  problems  solved  early  in  the  project  will  lead  to  more 
unsolved  problems,  and  that  those  solved  later  will  have  a 
higher  probability  of  not  making  new  unsolved  problems  visi- 
ble. A  crude  approximation  to  this  is  to  assume  that  the 
probability  of  a  solved  problem  not  generating  more  unsolved 
problems  is  linearly  proportional  to  the  number  cf  problems 
solved.   [  111  ] 
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How  does  the  above  relate  to  the  rate  at  which 
development  programs  can  be  made?  Clearly,  management:  can 
reduce  the  rate  of  progress  by  supplying  inadequate  re- 
sources. There  is  also  an  upper  bound  to  the  amount  of  ef- 
fort which  can  be  usefully  applied.  Sapid  progress  using 
large  amounts  cf  input  resources  is  possible  only  when  there 
is  scope  for  solving  problems  in  parallel.  In  practice,  a 
different  programmer  (or  possibly  a  team  of  programmers)  can 
be  assigned  to  each  separate  visible  unsolved  problem.  This 
suggests  that  the  rate  at  which  useful  work  can  be  applied 
is  proportional  to  V  (t)  ,  and  that  with  this  "optional"  input 
effort,  steps  in  the  development  will  be  achieved  at  a  rate 
proportional  to  V  (T)  . 

Whereas   the  Rayleigh   model  proposes  that   the 

rate  of  progress  will  be  proportional  to  the  skill  level  and 

number  of  problems  remaining,   the   above  has  argued  that  it 

is  proportional   to  the   visible  unsolved   problem  set.     A 

mathematical  expression  yields: 

2 
V(t)  =  (1/4)  sech   ((t  +  c  )/2)  (3.9) 

a  hyperbolic  function  symetric  in  t  with  an  integration  con- 
stant c  ;  while  the  Hayleigh  function  is: 
3 

2 
-  t  /2 
V  (t)  =  y«  =  te  (3. 10) 
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The  sech   model  closely  resembles   the  Rayleigh  model  in  the 

latter  half  of  the  curve,   but  the   front  tail   is  positive 

rather  than  zero  like  the  Rayleigh  (figure  3.8).  Thus,  in 

2 

the  sech   model,  projects  dc  not  have   well-defined  starting 

points.   This  accounts   for  work  done  prior   to  the  official 

project  starting  date. 


Rayleigh  curve 

2 
oooooooosech   curve 


workrate 
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Figure  3.8.   Sech  Curve 

One  cf  the  principles  of  software  programming  is 
that  decisions  initially  made  should  te  high-level  struc- 
tured ones  which  identify  components  for  subsequent  refine- 
ment. Increasing  the  complexity  of  the  initial  decisions  in 
this  manner  is  equivalent  tc  varying  the  distribution  of  the 
probability  of  a  solved  problem  generating  unsolved  ones. 
By  modifying  the  assumption  that  this  probability  is  linear, 
a  modified  workrate  function  can  be  derived: 
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V(t)  =    _    A  ex£  (-2  <Vt)  (3.11) 

(1  ♦  A  exp  (-2  o/t)) 

Thus,  it  may  he  seen  that  whereas  the  Rayleigh 
model  of  software  development  proposes  that  the  rate  of  pro- 
gress will  be  proportional  to  the  skill  level  and  number  of 
problems  remaining,  this  section  has  argued  that  it  is  pro- 
portional to  the  size  of  the  number  of  the  visible  unsolved 
node  set. 

Results  obtained  from  the  proposed  model  are 
similiar  to  the  Bayleigh  model,  excepr  that  account  is  taken 
of  work  contributing  to  a  project  wnich  precedes  its  offi- 
cial starting  date.  The  proposed  model  has  been  shown  to  be 
sufficiently  determined  for  ir  to  be  possible  to  account  for 
the  effect  of  different  programming  methodologies  on  the  na- 
tural work  associated  with  the  project. 

b.   Application  to  Maintenance  Costing 

Parr  suggests  that  exhaustion  of  the  problem 
space  is  the  main  cause  for  decrease  in  maintenance  effort 
at  the  end  of  ^he  project  profile  curve.  In  addition,  the 
structure  of  the  software  product  achieved  during  the  devel- 
opment could  affect  the  project  work  profile.  While  appli- 
cations  to   maintenance   costing   have   been   addressed  in 
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concept  only#  implications  are  that  integration  techniques 
for  determining  the  area  under  the  cur7€  at  a  specific  time 
pe-  riod  will  produce  results  similar  to  those  obtained  by 
using  Putna»fs  model. 

C.   CHAPTER  SUMMARY 

With  the  intsnt  to  gain  management  ccntrol  of  predicting 
maintenance  costs,  various  software  cost  estimating  methods 
and  philosophies  derived  from  observing  trends  and  patterns 
in  the  development  cycle  are  being  extended  to  encompass  to- 
tal system  costs.  Supportive  evidence  for  the  accuracy  of 
the  models  discussed  herein  is  contained,  for  the  most  part, 
in  software  life-cycle  simulations.  It  is  anticipated,  how- 
ever, that  the  acute  interest  and  increased  awareness  shown 
in  the  resource  investments  attributed  to  software  mainte- 
nance will  be  viewed  more  critically.  Although  lacking  in 
substantial  proof  for  predictive  validity,  these  models 
serve  as  stepping  stones  in  producing  a  composite  model  for 
tracking  maintenance  costs. 
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IV.   MANAGING  SOFTWARE  MAINTENANCE  COSTS 

Previous  chapters  have  addressed  topics  that  are  being 
critically  examined  for  their  impact  on  the  software  mainte- 
nance phase.  They  also  discussed  the  application  of  current 
development  software  cost  estimation  techniques  for  obtain- 
ing maintenance  costs.  The  focus  of  this  chapter  will  be 
the  presentation  of  a  method  for  arriving  at  a  well- 
structured  view  of  the  management  of  the  maintenance  phase 
of  the  software  life-cycle.  While  a  mathmatical  model  which 
accurately  explains  the  phenomena  of  the  maintenance  phase 
still  remains  elusive,  a  planning  and  control  model  has  been 
developed  to  aid  project  managers.  The  structure  of  the  mo- 
del embodies  two  distinct  concepts: 

1)  a  planning  concept  -  development  of  the  management 
strategy  to  cement  the  perceptions  of  the  maintenance 
issue ; 

2)  a  control  concept  -  procedural  analysis  for  estimating 
the  maintenance  manloading  requirements. 

Subsequent  sections  will  address  application  of  each  as- 
pect of  the  model  in  depth. 
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A.       PLANNING    CONCEPT 

1  •      RL2J3.£l  i?.§Iiac[ement 

Primary  responsibility  for  development  of  a  manage- 
ment strategy  belongs  to  the  project  manager  designated  -co 
manage  the  system  plan.  As  project  manager,  one  must  ini- 
tially determine  and  define  the  maintenance  requirement  of 
the  mission  profile  for  the  system  that  is  to  be  designed 
(i.e.    built-in   maintainability). 

Factors  which  must  be  considered  early  in  the  formu- 
lation of    a   maintenance   plan  include: 

1)  Probability  of  change  in  requirements.  tfhile  it  may  be 
impossible  tc  define  adequately  the  complete  require- 
ments for  a  large  program,  viewing  the  type  of  system 
application  (business,  scientific,  command  and  control) 
and  utilization  rate  will  serve  as  indicators  for  the 
amount  of  flexibility  to  be  considered  in  the  system 
design. 

2)  Software  performance  requirements.  Again,  application 
type    is   the    dictating   force    for   analyzing   this   factor. 

3)  Hardware  life-cycle.  In  planning  for  software  mainte- 
nance, the  interaction  of  the  nardware  and  software 
life-cycle    must    be  taken   into    account. 

2 .   Objectives  of  the  Maint enan ce  Concept 

Derivation  of  maintainability  requirements  from  the 
description  of  the  operational  requirements  provides  tne 
support  planning  criteria  on  which  to  base  the  maintenance 
concepts  appropriate  to  the  maintainability  requirement. 
The  maintenance   concept,   which  basically   defines  criteria 
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governing  the  sccpe  and  methods  applicable  at  each  echelon 
of  maintenance,  attempts  to  satisfy  the  quantitative  main- 
tainability requirement  derived  for  the  system  and  the  plan- 
ned support  environment  within  which  the  system  will  oper- 
ate. Early  development  cf  the  appropriate  maintenance 
concept  will  provide  a  definitive  and  uniform  basis  for  ac- 
complishing the  system  design  and  support  planning  tasks. 
3«   Establishing  the  Maintenance  Policies. 

System  effectiveness  is  jointly  dependent  on  several 
parameters,  of  which  performance  characteristics,  system  re- 
liability, and  operational  availability  appear  to  be  the 
most  critical.  In  effect,  these  parameters  set  baseline  re- 
quirements or  constraints  which  may  have  impact  upon  the  de- 
sign process  depending  upon  the  maintenance  policy  that  has 
been  established.  While  a  boundless  number  of  policy  varia- 
tions may  exist,  the  following  four  categories  identify  the 
range  of  policy  choices.  The  basic  distinction  among  these 
four  categories  lies  in  the  amount  of  resources  invested 
over  time  and  the  cumulative  benefit  received  over  time. 
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a.  Category  I  -  No  Management  Ccntrol 

A  steady  maintenance  effort  is  applied  with  no 
attempt  for  configuration  control  which  is  ensuring  that  a 
master  copy  of  all  operational  software  is  maintained.  Com- 
plexity of  the  program  will  eventually  reach  the  point  where 
locating  errors  and/or  making  changes  becomes  exceptionally 
difficult.  Gradually,  the  program  becomes  less  useful  until 
it  must  be  discarded  and  a  new  program  developed.  This 
policy  may  prove  to  be  cost  effective  for  situations  where 
it  is  known  that  the  nature  of  the  application  will  limit 
the  useful  life  cf  the  program. 

b.  Category   II  -  Permanent   Support   Level   with 
Periodic  Redevelopment 

As  in  Category  I,  a  steady  level  of  maintenance 
support  is  provided  by  a  permanent  workforce.  Redevelopment 
or  a  new  release  can  be  planned  for  at  regular  intervals  or 
in  response  to  a  specific  quantity  of  change  requests. 

c.  Category  III  -  Error  Repair  with  Major  Changes 
Manpower  support  is   set  at  the  level  needed  to 

correct  program  bugs.   External  programming  support  would  be 
required  for  making  major  changes. 
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d.   Category  IV  -  Error   Repair   Only  with   Periodic 

Redesign 

As  in  Category  III,  manpower  is  set  at  the  level 
needed  to   correct  an  unacceptable   design  error  or  program 
bug.    Change   requests  are  used  in   establishing  specifica- 
tions for  subsequent  design  of  a  new  program. 
4 .   Management  Structure 

Since  the  level  of  repair  policy  must  be  compatable 
with  the  maintainability  requirement,  the  maintenance  con- 
cept must  be  defined  for  each  management  level  of  mainte- 
nance established.  Beginning  with  the  lowest  level  of  us- 
ers, maintenance  concepts  are  implemented  with  subsequent 
policies  for  higher  management  levels  developed  to  support 
the  user  level  concept.  To  illustrate,  maintenance  may  be 
divided  into  three  echelons  as  discussed  below  and  shown  in 
figure  4.1. 

1)  User  level.  Maintenance  may  be  restricted  to  failure 
reports  and  system  restarts. 

2)  Organizational  level.  Technicians  perform  corrective 
maintenance.  Tasks  performed  would  include  location  of 
fault,  module  repair,  and  testing. 

3)  Contractor  level.  Maintenance  performed  at  this  level 
may  be  used  to  supplement  (augmented  support)  or  to 
replace  (sustained  support)  the  organizational  level 
support. 
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tions; major 
coding; 
rebuilds 

Figure  4. 1.   Maintenance  Levels 
5  •   System  Li  f  e-c_yc  le  Objectives 

Utimately,  the  maintenance  objective  is  to  achieve 
the  required  level  of  maintainability  in  delivered  systems 
with  an  optimum  balance  between  resource  support  require- 
ments and  potential  life-cycle  costs.  In  order  to  meet  this 
objective,  it  is  necessary  to  begin  the  system  life-cycle 
with  the  appropriate  conceptual  approach.  As  the  software 
product  passes  through  several  distinct  phases  in  its  evolu- 
tion, maintenance  prospects  can  be  enhanced  if  adequate  at- 
tention   is    taken    in   each    phase. 
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Figure  4.2  depicts  the  life-cycle  as  a  simple 
phase-to-phase  flow  diagram,  joined  by  critical  transition 
points  where  it  can  be  ascertained  that  the  required  main- 
tainability objective  has  been  achieved  before  transition  to 
the  next  phase.  These  transition  points  are  denoted  in  the 
figure  as  major  achievement  milestones.  Each  phase  compris- 
es several  areas  cf  management  endeavor  in  which  the  consid- 
eration of  the  system  maintainability  is  essential  to  the 
attainment  of  milestone  objectives.  The  software  product  is 
re-examined  at  each  milestone  to  determine  the  future  course 
based  on  progress  up  to  that  point.  As  each  milestone  ob- 
jective is  met,  maintainability  becomes  progressively  more 
tangible  as  a  built-in  feature  of  design.  Maintainability 
milestone    requirements   are   summarized   in   the   figure. 

Milestone  criteria  can  best  be  satisfied  by  syste- 
matic application  of  approved  procedures  in  the  performance 
of  evaluation,  management,  and  control  tasks  which  are 
geared  directly  to  specfic  objectives  of  individual  mile- 
stones in  the  life-cycle.  A  basic  approach  to  maintainabil- 
ity achievement  as  an  evolutionary  phase-to-phase  'growth1 
process    is   shown    in    figure   4.3. 
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Concept  Formulation  Phase  Hilestone  Criteria.  Maintain- 
ability requirements  derived;  maintenance  concept  estab- 
lished; maintainability  documented  in  system  specifica- 
tions; maintainability  milestones  and  task  requirements 
documented. 

(1)  Proceed  to  design  phase. 

Design  Phase  Milestone  Criteria,  Maintainability  design 
approach  and  maintenance  concept  optimized  by  tradeoff  and 
conformance  to  specified  requirements  and  economic  consid- 
erations; maintainability  requirements  and  milestone 
criteria  updated. 

(2)  Proceed  to  code  phase. 

Code  Phase  Milestone  Criteria.  Conformance  tc  specified 
maintainability  requirements  and  maintenance  concepts  ver- 
ified by  evaluation;  maintenance  control  procedures  de- 
fined in  support  documentation. 

(3)  Proceed  to  test  phase. 

Test  Phase  Milestone  Criteria.  Maintainability  degrada- 
tion factors  verified  by  test  and  evalution;  maintenance 
concepts,  repair  policies,  and  maintenance  procedures 
are  verfied. 

(4)  Software  product  is  approved  for  delivery. 

Service   Ose  Phase  Milestone  Criteria.  Maintainability 

characteristics,  maintenance  prodecures,  and  support  costs 

determined  by  periodic  assessment  cf  management  data; 
problem  areas  identified  for  correction. 

(5)  Initiate  change  request,  product  enhancement  or  new 
development;  repeat  life-cycle. 

Figure  4.2.   Maintenance  Milestones  in  the  system  Life-cycle 

3.   CONTROL  CONCEPT 

1 •   Objective  of  Ma inte nance  Control 

The   objective   of  this   thesis    was   to  develop   a 
methodology   for   arriving   at   a  good   prediction  of   pure 
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TASK  AREA 

LIFE-CYCLE 

PHASE 

TASK  REQUIREMENTS 

CF  |  D  J  C  |  T  1  3 

Determine 
Maintain- 
ability 
Require- 
ments 

* 

* 

i 

—  - 

i 

°  Establish  M  policies 
0  Derive  M  requirements 
°  Optimize  M  to  relia- 
bility, availibility, 
and  supportability 
°  Evolve  conceptual 
design  criteria 

Specify 
maintain- 
ability 
require- 
ments and 
milestone 
criteria 

* 

* 

■ 

* 

— 
* 

°  Define  M  requirements 
0  Define  M  milestone 

criteria  and  task 

requirements  in 

program  documentation 
°  Specifically  outline 

foregoing  requirements 

in  contractual 

documents 

Achieve 

specified 
maintain- 
ability 
in  design 

* 

* 

°  Identify  and  define  M 
problems  and  critical 
areas 

°  Integrate  M  enhance- 
ment into  design 

°  Verify  design  conform- 
ance to  specific 
requirements 

°  Review  impact  of  pro- 
posed changes  on  a 
design  characteristics 

Show  ade- 
quacy of 
maintain- 
ability in 
develop- 
ment 

* 

♦ 

°  Prepare  detailed  plans 
for  maintenance  test 

°  Demonstrate  adequacy 
of  maintenance  manuals 

Achieve 
optimum 
mainte- 
nance 
support 

* 

* 

* 

* 

* 

0  Develop  maintainence 

plan,  repair  policies, 

and  procedures 
°  Develop  maintenance 

training  program 
°  Prepare  contractor 

support  plan 

Evaluate 

maintain- 
ability 

at  service 

level 

* 

0  Verify  conformance  to 
M  requirements  under 
service  conditions 

°  Verify  adequacy  of 
maintenance  support 
manuals 

0  Evaluate  skill 
requirements  and 
adequacy  of  training 
program 

CF  =  Concept  Formulation 

C  =  Code 

S  =  Service  Use 


£  =  Design 
1  =  Test 


Figure  4.3.   Maintenance  Tasks  in  the  System  Life-cycle 
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maintenance   costs.   Determining  the  requirements  for  pure 
maintenance  is  considered  valuable  in  that 

1)  estimates  can  be  calculated  of  the  manloading  necessary 
to  form  a  maintenance  support  team  which  is  composed  of 
either  in-house  or  contract  augmentation; 

2)  projections  can  be  made  for  outyear  maintenance  support 
and  availability  of  manpower  resources  for  developmen- 
tal work. 

With  future  research,  the  application  of  this  model 
may  be  extended  to  any  software  project;  however,  access  and 
availability  of  data  precluded  analysis  of  small  and  medium 
sized  projects.  Only  data  from  major  projects  was  analyzed 
for  developing  a  computational  algorithm. 

In  executing  the  computational  algorithm,  both  macro 
(system)  and  micro  (functional  area  component)  techniques 
are  used  concurrently  tc  increase  the  validity  of  the  esti- 
mates. An  implicit  assumption  worth  noting  is  that  each 
method  should  provide  reasonably  close  estimates  for  the 
same  project.  The  macro  technique,  of  course,  is  based  on 
total  system  characteristics  and  will  provide  the  gross  man- 
ning requirements  directly.  Alternately,  from  the  micro 
technique,  summation  of  the  decomposed  functional  areas  will 
yield  the  gross  manning  for  the  total  system. 


94 


2.   Model  Deriyiaticn 

The  data  under  study  was  taken  from  a  large-scale 
project  reported  by  USACSC  £112]  and  unpublished  data  from 
the  IBM  Space  Shuttle  Program  [113], 

a.   Macro  Technique 

Using  the  Eayleigh  curve  parameters  derived  by 
Norden  and  Putnam  [114,  115],  a  method  was  constructed  for 
obtaining  total  system  maintenance  requirements  applicable 
to  the  established  management  strategy.  In  his  early  work, 
Norden  made  note  of  the  fact  that  the  Eayleigh  curve  of  a 
project  profile  has  a  point  of  inflection  at  which  the  de- 
crease in  utilized  manpower  slows  down  in  the  descending 
portion  of  the  curve, 

3  \V2 

ip   (  .a  j 

where 

t    =  the  inflection  point  of  the  project  curve 
ip 

a   =  the  shape  parameter  or  spread  of  the  curve. 

The  point  of  inflection  may  have  more  signifi- 
cance than  originally  recognized.  If  it  can  be  shown  that 
the  level  of  effort  for  the  maintenance  phase  reaches  a  max- 
imum at  this  point,   the  manlcading  estimate  calculated  from 


95 


this  point   can  fc€  used  as  the  upper  bound   for  maintenance 

support.   In  essence,   the  current   model   suggests   a   new 

mechanism  for   determining  the  level  of   maintenance  support 

required.    Gained  from  the  model  is  the  benefit  of  relating 

the  work  profile  more  directly  to  the  intrinsic  structure  of 

•che  project  profile. 

To  simplify  calculations,  the  project  profile  is 

normalized  with  respect  to  t   and  y»     as  shown  in  figure 

d        max 

4.4.  Total  life-cycle  (K) ,  has  a  normalized  value  of  1. 
Based  on  this  assumption  and  using  Sayleigh  curve  relation- 
ships, it  can  be  shewn  empirically  that  the  peak  of  mainte- 
nance effort  occurs  at  the  inflection  pcint. 


(y/y   ) 

max 


(0.38  y»     ) 

max 


(0.26  y»    ) 
max 


Figure  4.4 


d         ip      im 
Normalized  Rayleigh  Curve 
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From   the  normalized  curve   values,   the   shape 

parameter  is  found  with  the  following  relationship: 

1 
a  =   — -   =  0.5  (4.2) 

2t 

d 

Substituting  this  value  of  a  in  the  following  equation,  the 
inflection  point  (t   )   of  the  project   profile  is  obtained. 

/  3  \V2 

t    =  / =    1.73  years.  (4.3) 

ip     (2a  J 

Manloading  requirements   at  time  t     (y1     ) 

ip      1.73 

can  be  shown   mathematically  to  be  equal  to  the  maximum  man- 
load  (y'   )  which  occurs  at  the  peak  (t  )  of  the  maintenance 
t  m 

■ 

phase   profile.         Stated   in   the   format  of   a   mathmaticai   equa- 
tion,   this    equality   has   the   form 

(project   inflection        -         (maximum    maintenance 
point  manning)  phase   manning) 

or  y«  =  y»  (4.4) 

t  t 

ip  m 

Substituting  normalized  values  into   the  Rayleigh  (manpower) 

equation 

2 
(-.05)  (1.73) 
y1       =  2(1)  (.05)  (1.73)  e  (4.5) 

(1.73) 

y1       =  0.38  manyears.  (4.6) 

(1.73) 
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In  order   to  calculate   maximum  manning   for  the 

maintenance  phase,  parameters  for  the  maintenance  curve  musr 

be  defined.  Actual  time  elapsed  between  the  beginning  of  the 

maintenance  phase  (t  )  and  the  maximum  level  (t  )  is  comput- 

o  m 

ed    using      empirical      data    recorded    by   OSACSC.        Results   from 

the      OSACSC   research      indicate   that      the   maintenance      phase, 

which   accounts      for   twenty   percent      of    the      total   life-cycle 

manpower    (K) ,      begins   at   approximately      1.3    years   normalized 

time.      With   this    estimation,   actual   time   elapsed    (t   )    can    be 

e 

found   by 

t      =   t      -   t   =   0.43   years.  (4.7) 

e  m  o 

The    spread     of   the      maintenance      curve      (a   )      is 

m 

determined  by  subtituting  the  elapsed   time  value  into  the 

already  familiar  equation 

1 

a   = =   2.71  (4.8) 

m  2 

2(t  ) 

e 

The  value  cbtained  for  the  shape  parameter  suggests  a  curve 
having  a  wide  spread,  an  expected  characteristic  of  the 
maintenance  phase  profile  curve.  Computation  of  the  maximum 
manloading  for  the  maintenance  phase  from  the  basic  manpower 
equation  gives 
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2 
(-2.71)  (.43) 
y«      =  2(.2K)  (2.71)  (.^e1  (4.9) 

( t  ) 

m 


y'      =   0.38   =  y»  (4. 10) 

(t  )  (t.  ) 

m  ip 

With   y'   defined  to  be   the  upper   boundary  for 

the  maintenance  effort,   another   boundary  can  be  identified 

as  the  lower  limit  for   maintenance  effort.    By  determining 

the  value  of  the  inflection  point  of  the   maintenance  curve 

(t   ) ,  a  minimum  support  level  can  be  found  from 
ia 

3  \/2 

t    =  f \        =    .74  years.  l<*.11) 

ira    |2a 

m  I 

Converting  this  time  to  normalized  time  (t  ) 

n 

t   =  t   ♦  t  (4.  12) 

n    o    im 

t   =  1.3  ♦  .74  =  2.04  years  (<*.13) 

n 

and  substituting   this      value   in   the    manpower  equation   yields 

y«  =    .25    manyears.  (4.  14) 

(2.04) 

The  manpower  loading   calculated  for  the  inflec- 
tion point  of  the   maintenance  phase  (t   )   closely  approxi- 

im 

mates  the   value  identified   by  USAC3C   as  the   steady  state 

level  of   effort.    Establishing  maintenance  at   the  minimum 

level  can  be  interpreted  as  a  Category  IV  policy. 
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b.   aicrc  Technique 

Decomposition,  more  commonly  referred  to  as  the 
work  breakdown  structure  (WBS)  method,  has  been  a  predomi- 
nate methodology  for  estimating  manning  resources.  A  system 
is  considered  to  contain  subsystems  which  are  further  divid- 
ed into  smaller  hierarchial  structures  until  the  smallest 
programing  element  is  reached.  Once  the  functional  areas 
are  defined,  characteristics  (complexity,  productivity,  er- 
ror rate,  etc.)  of  each  must  be  reviewed  to  determine  the 
level  of  effort  needed  for  maintenance.  Appendix  A  contains 
an  example  of  a  micro-estimating  methodology  along  with  the 
sample  data  used. 

3  .   Sample  A££l icat ion 

a.   Sample  Data 

Data  used  for  this  sample  application  of  the 
control  concept  was  provided  by  IBM  Federal  Systems  Space 
Shuttle  Program  £  116  3-  The  raw  manning  data  is  provided  in 
Appendix  A.  The  remainder  of  this  section  is  a  step-by-step 
example  of  the  ccmputicnal  algorithm  which  implements  the 
control    concept    of   the    proposed  model. 
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MY 


time 


t      t 
ip     im 


Project  Curve  Parameters 


=  2.5 


K   =  1343 


a   =  .08 


y»     =  325 

max 


!K5TE~T: 

MSB  =  maintenance  support 
boundary 

Boundary  level  established 
from  analysis  of  macro  and 
micro  estimations. 


Maintenance  Su££ort  Level 
(1)  Macro  technique 
t 


(4.33* 


lm 

y 


(5.1) 


=  4.33 
=  207  manyears 
=5.1  years 
=  137  manyears 


(2)  Micro  technique 

y  =  component  manning 
c 

Zy  =  195  manyears 
c 


(refer  to  Appendix  A) 


Figure  4,5.   Plotted  Sample  Data 
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b.  Computational  Algorithm 

Step  J.  Fit  the  actual  budget  data  to  a  Ray- 
leigh  curve.  Figure  4.5  shows  plotted  data  for  the  Space 
Shuttle  program. 

Ste£  2.  Determine  maintenance  support  boundary 
lines  by  calculating  the  inflection  points  of  both  the  pro- 
ject profile  and  maintenance  phase  curve. 

Step  3.  Determine  support  level  requirements 
using  micro-estimating  techniques. 

Step  4.  Compare  values  obtained  from  macro  and 
micro  methods.  Analyze  the  differences  from  an  economic 
standpoint  based  en  management  policy. 

Step  5.  Predict  outyear  budget  requirements  for 
maintenance/new  development  contingent  on  management  policy. 

c.  Management  Applications 

Although  the  results  shown  here  relate  to  only 
one  set  of  data,  they  are  encouraging  in  the  support  they 
give  the  model.  The  model  presented  in  this  thesis  could 
provide  a  direct  means  to  evaluate  the  impact  of  current  and 
future  management  practices  on  the  life-cycle  cost  of  tae 
software  system.  The  idea  of  the  development  of  a  mainte- 
nance  strategy   coupled  with   the  use  of  the  computational 
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algorithm  provides  the  project  manager  with  some  powerful 
management  tools.  While  additional  research  is  warranted, 
it  is  purported  that  application  of  the  model  will  prove 
enlighting  in  the  following  respects. 

C)  Determining  Maintenance  Support  Level. 
Preliminary  estimates  obtained  from  inflection  point  predic- 
tors may  be  used  as  a  starting  point  for  planning  workforce 
reguirements  to  be  drawn  from  internal  assets.  Likewise,  if 
external  or  contracted  support  must  be  procured,  evaluations 
of  submitted  bid  proposals  will  be  necessary.  Although  yet 
unproven  statistically   for  accuracy,   the  inflection   point 

predictors   appear  to  define  maximum  (t   )  and  minimum  (t   ) 

ip  im 

boundaries  for  maintenance  levels. 

In  accordance  with  the  type  of  maintenance 
strategy  chosen,  a  maintenance  level  boundary  can  be  select- 
ed. For  example,  if  a  Category  IV  policy  is  selected,  man- 
power needs  would  approach  the  minimum  boundary.  On  the 
other  hand,  a  Category  I  policy  would  require  resources  ap- 
proximated by  the  maximum  level.  With  these  boundaries  to 
serve  as  guidelines,  contract  proposals  can  be  viewed  more 
critically. 
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(2)  Forecasting  Resource  Distribution.  Whether 
an  internal  or  external  workforce  is  used,  planning  and 
budgeting  estimates  of  manloading  are  usually  projected  for 
discrete  timeframes.  During  the  maintenance  phase  of  a  via- 
ble project,  the  workforce  in  terms  of  total  number  remains 
stable;  however,  the  work  distribution  or  functional  roles 
of  personnel  may  change  (i.e.  programmers  may  shift  from 
maintenance  work  to  development  work) .  Within  governmental 
agencies,  this  stability  may  be  attributed  to  fixed  contract 
levels  or  established  manning  levels,  neither  of  which  can 
be  easily  changed.  Therefore,  the  management  problem  be- 
comes one  consisting  not  only  of  how  many  personnel  are 
needed,  but  also  hew  can  assets  best  be  utilized. 

In  light  of  the  fact  that  the  users  have 
changing  reguirements,  the  issue  of  workforce  allocations 
for  new  research  and  development  must  be  considered.  3ased 
on  the  Rayleigh  curve  characteristics  for  a  specific  project 
and  using  a  fixed  support  level  environment,  approximate 
values  for  workload  distribution  can  be  calculated. 

By  method  of  integration,  the  proportion  of 
the  total  support  level  force  that  will  be  dedicated  to  pure 
maintenance  and/cr  new  development   in  future  timeframes  can 
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be  calcalated.    Figure  4.6  illustrates  this  point  using  the 
sample  data. 


MY 


MSB  =  y» 


year 


J 


MS3  - 


-at 
2Kate 


dt 


=  20 7t  | 


16 


15 


-  1343e 


-at 


6 
I  5 


=  101  MY  (resources  available  for  new  development) 

Note  1: 

MSB  =  maintenance  support  boundary.  In  this  example,  the 
boundary  is  established  at  the  project  profile  inflec- 
tion point.  Alternately,  the  boundary  would  be  estab- 
lished to   indicate  the  manning   level  of   the  mainte- 


nance workforce. 


Figure  4.6.   Forecasting  Future  Requirements 

Maintenance  information  gained  with  this 
oversight  method  is  twofold.  The  separation  of  development 
work  (enhancements,  additions,  new  design)   from  maintenance 
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work  (debugging,  design  error  correction)  is  accomplished, 
-hereby  allowing  for  tetter  interpretation  of  the  project 
investment.  The  comparison  of  the  relative  proportion  of 
maintenance  manning  versus  development  manning  for  reviewing 
project  viability  can  also  be  made.  This  concept  will  be 
discussed  more  fully  in  the  next  section. 

(3)  Monitoring  Configuration  Control.  A  pauci- 
ty of  available  data  prevents  the  comparison  of  actual  and 
predicted  manpower  that  is  required  during  the  maintenance 
phase.  The  assumption  that  the  maintenance  tail  is  flat  or 
reaches  a  steady  state  seemingly  arose  from  this  lack  of  in- 
formation. It  is  the  authors'  contention  that  new  releases 
of  a  software  product  may,  in  fact,  cause  increases  in  the 
maintenance  tail  ever  time. 

Lehman  and  fleiady^  [117,  113]  research, 
discussed  in  chapter  3,  gives  strong  indications  that  subse- 
quent releases  for  a  software  product  increase  complexity 
and  the  amount  cf  antigressive  (maintenance)  work  that  is 
required  for  the  total  system.  Two  inherent  characteristics 
of  the  software  product  directly  affected  by  a  new  release 
are  the  system  configuration  and  the  size  of  the  system 
problem  space.   From  a  project  profile  view,  the  time  period 
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when  these  new  releases  occur  is  during  the  maintenance 
phase.  With  the  assertion  that  the  work  allocated  to  the 
completion  of  a  new  release  must  be  considered  as  a  phase 
within  the  project  life-cycle,  the  increase  in  maintenance 
costs  can  be  explained. 

As  the  diagram  in  figure  4.7  indicates,  the 
changes  induced  by  the  release  phase  will  cause  the  level  of 
maintenance  to  increase.  Unless  carefully  monitored,  each 
new  release  may  cause  an  increase  in  the  maintenance  re- 
quirements until  the  original  maximum  maintenance  support 
level  is  reached  or  exceeded.  When  this  occurs,  management 
is  forced  to  make  a  cost-benefit  assessment  of  the  software 
system. 

Using  the  concepts  introduced  earlier  (in- 
flection point  predictors  and  resource  distribution  fore- 
casting) ,  maintenance  saturation  of  the  software  system  can 
be  detected.   The  support  line  obtained   from  the  inflection 

point  predicter  (t      )  serves  as  a  guideline  for  total  system 

ip 
saturation.   Management  policy  sets  forth  limits  for  corres- 
ponding  maintenance   and/cr  development  expenditures  which 
establishs   a   budget   saturation   level.   These   saturation 
levels  may  be  equal  or  different.   In  an  attempt  to  preclude 
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Figure  4.7.   New  Release  Effect  on  Maintenance  Level 
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excessive  maintenance  costs,  the  saturation  level  viewed  as 
dominant  is  used  to  trigger  management's  attention  toward  a 
system  rebuild.  For  the  subsequent  rebuilt  system,  a  new 
Rayleigh  curve  is  plotted  and  a  new  cycle  of  planning  and 
contol  begins. 

C.   CHAPTER  SUMMARY 

Presented  in  this  chapter  is  a  bilevel  model  for  manag- 
ing software  maintenance  costs.  The  model,  composed  of  both 
a  planning  concept  and  a  control  concept,  suggests  that  the 
creation  of  a  management  strategy  will  have  far-reaching  ef- 
fects in  the  system  total  life-cycle  costs.  Used  concur- 
rently, the  two  model  concepts  allow  for  smoother  transla- 
tion of  maintenance  objectives  between  the  strategic 
olanning  level  and  the  operational  control  level. 
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V.   SUMMARY,  CONCLUSIONS,  AND  RECOMMENDATIONS 

Presented  in  this  chapter  is  a  summary  of  the  thesis, 
general  conclusions,  and  recommendations  for  further  study. 

A.   SUMMARY 

Various  methodologies  and  system  factors  relating  to 
software  cost  accounting  have  been  reviewed  in  an  attempt  to 
develop  a  cost  model  for  the  prediction  of  pure  maintenance 
costs.  The  distinction  between  development  costs  and 
maintenance  costs  is  considered  necessary  in  order  to  pre- 
sent a  realistic  picture  of  the  annual  expenditures  within  a 
given  budget  constraint.  Without  a  refined  separation  of 
these  two  cost  entities,  budget  control  is  a  more  difficult 
task. 

Beginning  with  a  broad  background  of  what  maintenance  is 
and  is  not.  Chapter  One  uncovers  the  paradox  that  exists  in 
obtaining  a  consensus  for  a  common  working  definition  of 
maintenance.  Different  schools  of  thought  within  the  mili- 
tary and  civilian  research  fields  have  produced  inconsisent 
results  when  citing  the  proportion  of  the  the  life-cycle 
costs  attributable  to  total  system  costs.  This  inconsis- 
tency may  be  due,   in  part,   to  the  range  of  cost  types  (new 
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development,  pure  maintenance,  other  administrative  support 
activities,  etc.)  that  exist  during  the  maintenance  phase. 
While  some  researchers  may  view  each  cost  type  individually, 
others  consider  the  maintenance  costs  to  be  an  aggregate  or 
all  expenditures  during  the  maintenance  phase. 

In  Chapter  Two,  an  overview  of  the  extrinsic  and  intrin- 
sic charactistics  of  a  software  system  which  create  the 
maintenance  setting  is  prcvided.  It  is  apparent  from  the 
detailed  discussion  of  the  more  salient  concepts  that  the 
maintenance  issue  is  not  only  complicated,  but  also  still 
somewhat  elusive.  While  these  concepts  have  been  useful  in 
explaining  system  characteristics  and  predicting  future  be- 
havior, they  fail  to  produce  a  means  for  direct  translation 
to  a  monetary  value. 

Although  no  cost  estimation  technique  adaptable  for  man- 
agement use  has  teen  developed  solely  fcr  predicting  mainte- 
nance costs,  application  of  software  cost  estimating  schemes 
originally  intended  to  evaluate  the  development  phase  have 
been  extended  tc  include  the  maintenance  phase.  Chapter 
Three  is  devoted  to  a  review  of  various  models  that  have 
been  suggested  as  appropriate  for  addressing  the  maintenance 
cost  uncertainties.  The  models  two  avenues  for  approaching 
the  issue: 
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1)  a  total  system  concept  using  the  Norden-Rayleigh  curve, 
and 

2)  a  dynamic   system  philosophy   using  software  evolution 
analysis . 

Current  unavailability  of  a  basic  method  for  adequately 
determining  miantenance  expenditures  and  the  increasing  con- 
cern of  DOD  for  the  exorbitant  funding  required  to  sustain 
software  system  operations  inspired  the  authors  to  develop  a 
flexible  management  model.  Chapter  Four  elucidates  a  plan- 
ning and  control  model  which  can  provide  project  managers 
with  additional  information  to  assist  in  budget  planning  and 
decision  making.  This  model  proffers  four  maintenance  stra- 
tegies which  may  be  used  in  conjuction  with  calculated  maxi- 
mum and  minimum  maintenance  level  support  boundaries  specif- 
ic to  the  project  profile. 

3.   CONCLUSION 

While  an  abundance  of  research  in  software  economics  and 
software  engineering  exists,  very  little  has  been  done  that 
relates  to  the  maintenance  phase  of  the  software  life-cycle. 
As  a  result,  there  is  an  obvious  lack  of  raw  data  available 
to  analyze  the  proposed  model  for  validity  and  sensitivity. 

With  additional  research,  it  is  believed  that  the  model 
presented   in  this   thesis  will   provide  a   direct  means   to 
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evaluate  the  impact  of  current  and  future  management  prac- 
tices on  the  life-cycle  costs  of  software  systems.  The  com- 
bined use  of  the  simple  macroestimating  and  microestimating 
techniques  allows  the  manager  to  look  at  the  maintenance 
problem  from  different  perspectives  while  increasing  the 
confidence  in  the  projected  maintenance  costs.  Additional- 
ly, the  computation  of  minimum  and  maximum  levels  of  effort 
for  a  specific  project  leads  to  further  diminution  of  the 
problem  when  management  has  established  a  particular  mainte- 
nance strategy. 

C.   RECOMMENDATIONS 

It  is  recommended  that  additional  work  within  DOD  be  un- 
dertaken to  further  the  research  objectives  of  software 
maintenance  costs  and  that  this  work  include  the  following 
actions: 

1)  adoption  of  a  standard  definition  that  will  distinguish 
between  maintenance  costs  and  costs  incurred  in  the 
maintenance  life-cycle  phase; 

2)  institution  of  longitudinal  research  by  software  sup- 
port facilities  to  collect  maintenance  data  to  be  used 
m  the  development  of  management  tools  with  improved 
capability; 

3)  investigation  of  the  usage  of  additional  prediction 
tools  to  obtain  a  more  complete  view  of  the  domain  of 
software  behavior  during  the  maintenance  phase;  and 

4)  analysis  of  empirical  data  to  prcve  or  disprove  the 
following  statement:  The  more  over-budget  and  behind 
schedule  that  a  project  is  delivered,  the  higher  shouid 
be  the  prediction  of  errors  detected  in  the  maintenance 
phase. 
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APPENDIX  A 
Contained  in  the   following  text  is  a   partial  sum- 
mary of  a  microestimating  technique  (Matrix  Estimation 
Process)   obtained   from  IBM  federal   systems  Division, 
Houston,  Texas. 

J*ilIIX  METHOD 
Definition:  The  Matrix  Method  is  a  systematic  procedure 
which  can  be  used  to  delineate  elements  of  a 
software  project  and  map  them  against  associat- 
ed ccst  elements  to  arrive  at  a  project  esti- 
mate. 
Things  that  can  be  accomplished: 

0   Lay  out  project  elements 

°   Stepwise  refine  the  elements 

°   Estimate  the  elements 

0   Subtotal  the  estimates  by  grouping 

the  elements 
°   Total  up  the  group  estimates 
0   Refine  total  estimate 
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Use  of  the  Matrix  Method 

1.  Determine  functional  elements  of  project. 

2.  Quantify  Maintenance  needs  based  on  : 

Level  =   Function  Size  /  ((Productivity)    (Complexity) 
(Factor) 

3.  Consider  critical  skills,   operations  support,   and  man- 
agement and  support. 

U.   Summarize  for  project. 
5.   Plot  with  Rayleigh  curve. 
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Matrix  Estimation  Process 

1.  Lay  out  a  table  of  functional  areas  of  code,  require- 
ments areas,  test  areas,  or  functions  to  be  performed. 
Using  the  following  formulas,  calculate  the  level  re- 
quired to  maintain  each  functional  area  or  function: 

Applications  Level  =  (FW  Size)/((154)  (2)  (12)  (2)) 

FCOS  Level  =  (FW  Size)/ ((100)  (2)  (12)  (2)) 

SDL  Level  =  (K  Line  Size)/((15)  (2)) 

Computer  Resource  =  (FEID  Hrs  Wk)  /  (28) 

GN&C  Verfi.  Level  =  (Number  Test  Cases)/((30)  (2)) 

SStf  Verif.  Level  =  (Number  Test  Cases)/ ((5)  (2) 

SM/PL  Verif.  Level  =  (Number  Test  Cases)/((20)  (2) 

Perf.  Verif.  Level  =  (Number  Test  Cases)/((5)  (2) 

All  Others: 

Level  =  (Development  or  Support  Level) /(2) 

TSO  Level  =  Requested  support  level  per  site 

2.  Look  at  critical  skills  to  see  if  each  functional  area 
is  adequately  covered. 

3.  Estimate  error  rate  and  rate  of  change  to  see  if  level 
should  be  altered. 
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MATHIX  ESTIMATE  SUMMABY* 

Haint.  cpn  s 

Area        Size        Level  Support  M&S  Total 

AASD         272918  FW    42.0        12.0  10.0  64.0 

CON/QA        5.0        1.0  6.0 

SEC.  SUPP     11.0        11.0 

ASVO                            1247    TC         83.5                    5.0  15.5  104.0 

140.5  17.0  26.5  195.0 


*  Matrix  Summary  represents  decomposition  of  the  Space  Shut' 
tie  Program  intc  major  functional  areas. 
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AASD  Matrix  Estimate  Summary  * 


Code 

Ma int. 

OPN  S 

Area 

Size 

Level 

Support 

M&S 

Total 

SM 

54880 

6.7 

3.0 

1.3 

1  1.0 

VCO 

57145 

5.2 



.8 

6.0 

GN&C 

129918 

16.7 

4.0 

2.8 

23.5 

a. a. 

10.4 

5.0 

2.6 

18.0 

P.  A. 

30975 

3.0 



.5 

3.5 

AASD 
M&S 







2.0 

2.0 

Totals 

272918 

42.0 

12.0 

10.0 

64.0 

*  Note :   This  table   illustrates  an   additional  decomposition 
of  a  major  functional  area  into  subcomponents. 
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Plotted  Sample  Data 


MY 


o o  project  data  points 

* *  support  level 


1/82    1/83 

(year) 


PROJECT  CURVE  PARAMETERS 


t   =  2.5 

a 


k   =  13U3 


a   =  .08 


y*     =  325 

max 
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